-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API for testing emitted events #6
Comments
I'll go ahead and begin implementing this tomorrow. @eddyerburgh could you set as in progress in that todo list when you have a sec so that others don't duplicate effort. |
What about making it |
I think there needs to be more discussion on this before we build anything. Personally, for methods like wrapper.vm.$on
wrapper.on
wrapper.vm.$emit
wrapper.emit
wrapper.vm.$destroy
wrapper.destroy Otherwise we'll end up with a huge API. Although maybe on and emit are such common use cases that we should include them as methods. |
Thought about this a little more. I can make a good case for either one of these directions. What do you think about keeping the number of things the library does to a minimum initially and going with encouraging using |
Closing: can reopen and implement after we have more information on what we are needing. |
Reopen as I am revisiting this feature. After having to manually create spies for all the events I wanted to assert, it felt quite tedious. I am proposing an API that requires minimal setup by simply auto-recording all emitted events in a Say you emit the following events: wrapper.vm.$emit('foo', 1)
wrapper.vm.$emit('foo', 2, 3)
wrapper.vm.$emit('bar') Then {
foo: [[1], [2, 3]],
bar: [[]]
} This simple data structure allows all kinds of assertions: // assert event emitted
expect(wrapper.emitted.foo).toBeTruthy()
// assert event count
expect(wrapper.emitted.foo.length).toBe(2)
// assert event payload
expect(wrapper.emitted.foo[0]).toEqual([1]) The best part is you don't need to do any wiring or setup, you can just assert it after you trigger the events. |
I think this is an elegant solution, and we should implement it. Are you able to make a PR @yyx990803? I'm happy to if you're not. |
That absolutely looks like a very clean approach on the events. I support @eddyerburgh view regarding keeping the API minimal and encourage using the On the comment from @yyx990803 I think that's a piece of API that brings the test-utils forward. |
Closed with 0033c4a |
Related to TODO in #4
Some ideas
The text was updated successfully, but these errors were encountered: