Feedback #36
Feedback #36
Conversation
|
|
||
| ## `VueWrapper.emitted()` | ||
| ## Asserting the emitted events |
There was a problem hiding this comment.
Here people got lost because we moved from explaining thing from a "user perspective" to an "API perspective"
| expect(wrapper.emitted('increment')[2]).toEqual([3]) | ||
| // We have "clicked" twice, so the array of `increment` should | ||
| // have two values. | ||
| expect(wrapper.emitted('increment')).toHaveLength(2) |
There was a problem hiding this comment.
Reduced clicks from 3 to 2 because otherwise the snippet grows too large
| We trigger the `click` event listener, triggering the `submit` method. Similar to `setValue` we are using `await` to make sure the action is being reflected by Vue. | ||
|
|
||
| We can then assert that some action has been performed, like if the emitted event has been called. | ||
| > If you haven't seen `emitted()` before, don't worry. It's used to assert the emitted events of a Component. You can learn more in [Event Handling](/guide/event-handling). |
There was a problem hiding this comment.
They found this internal links really helpful because they allow them to quickly explore related features.
| expect(wrapper.emitted('submit')[0][0]).toBe({ | ||
| email, | ||
| description, | ||
| city, | ||
| subscribe: true, | ||
| interval: 'monthly', | ||
| }) |
There was a problem hiding this comment.
It was weird for them finding an "incomplete" example here
| * Use `setValue` to set the value on both DOM inputs and Vue components. | ||
| * Use `trigger` to trigger DOM events, both with and without modifiers. | ||
| * Add extra event data to `trigger` using the second parameter. | ||
| * Assert that the DOM changed and the right events got emitted. Try not to assert data on the Component instance. |
There was a problem hiding this comment.
Collapsed a couple of bullet points into one
| @@ -43,9 +43,9 @@ export default { | |||
|
|
|||
| There are several things we need to do to test this component properly. | |||
|
|
|||
| Our first goal is to test this component **without actually hitting the API**. This would create a fragile and potentially slow test. You should be able to run your test suite while being offline. | |||
| Our first goal is to test this component **without actually reaching the API**. This would create a fragile and potentially slow test. | |||
There was a problem hiding this comment.
The "run tests while offline" felt a bit off. They misunderstood it – they thought it was about testing what happens with the component when offline.
| // Here we are implicitly asserting that the | ||
| // element #profile exists. | ||
| const profileLink = wrapper.get('#profile') | ||
|
|
||
| expect(profileLink.text()).toEqual('My Profile') |
There was a problem hiding this comment.
They didn't get why this test had no assertions
| <button @click="handleClick">Increment</button> | ||
| <div>Count: {{ count }}</div> | ||
| `, | ||
| template: '<button @click="handleClick">Increment</button>', |
There was a problem hiding this comment.
The <div>Count: {{ count }}</div> part is not used during tests, so I removed it
|
I'm gonna merge this one, we can always keep iterating 😉 |
Hi folks!
As mentioned on Discord, last week I had the chance to run a testing workshop with some colleagues, and we gave VTU-next a go.
Good news: no "technical" issues/bugs were found! The workshop was quite introductory, so this was kinda expected. We didn't get that far. Still, great job folks!
Better news: I told them to rely on docs before asking, and we could identify several issues and potential improvements ❤️
This PR aims to address the feedback I collected. It was mostly related to "knowledge leaps" and several assumptions we made. It makes total sense, since these people were quite new at testing Vue, so they required more guidance.
I tweaked stuff in:
As usual, feel free to suggest any modification, any addition, or any rollback :)