VueTestUtils 2 API proposal for Vue 3

[dobromir-hristov]

TLDR

VueTestUtils 2.x, which targets Vue 3, will introduce a few new methods and remove some less used ones. Usage should stay mostly the same.

• Breaking: sync mode removed. All mutation methods return nextTick, you must await them.
• Breaking: find is now split into find and findComponent.
• Breaking: Removal of some wrapper properties and methods, as they induce bad testing habits or are obsolete.
• Breaking: shallowMount stubs defaults slots
• Breaking: setProps only works for the mounted component.

Note: The API for VueTestUtils 1.x will stay the same and will support Vue 2.x.

Rendered

[xanf]

While having everything affecting global things in global is perfect, thank you for this, I'm a bit concerned about provide. From what I understand We have two things in "global":

• things which are registered globally in real world application (components, directives, mixins, plugins)
• things which are VTU-specific but affect each component in the tree (stubs, mocks)

provide is just providing data for provide/inject, and for example providing foo in global.provide does not guarantee that my value will be always injected in component somewhere deep in the tree - it could be easily changed by provide in some ancestor

Maybe it's worth to keep this our of global object since its behavior is different?

[dobromir-hristov]

This RFC is now in final comments stage. An RFC in final comments stage means that:

The core team has reviewed the feedback and reached consensus about the general direction of the RFC and believe that this RFC is a worthwhile addition to the framework.
Final comments stage does not mean the RFC's design details are final - we may still tweak the details as we implement it and discover new technical insights or constraints. It may even be further adjusted based on user feedback after it lands in an alpha/beta release.
If no major objections with solid supporting arguments have been presented after a week, the RFC will be merged and become an active RFC.

[kspackman]

I am in the process of upgrading to v1.0 and working through the deprecations within our application. Most everything that has been deprecated, I can use an alternative to achieve the same end, or rewrite to improve the test, which is great.
I have one proposed change that I have concerns about though. We often have parent components that may contain multiple instances of the same component as children, but we want to target a specific instance within the unit test. We often will do something like the following:
wrapper.find('thead').findComponent(MyComponent)
But with the proposed changes, this cannot be done. The only feasible alternative I see to be able to still target a specific component is to add refs to everything. I don't like adding things to production code solely for the sake of unit testing, though, so I really don't want to do that.
Do you have any other alternatives to allow me to still be able to target specific instances of components?

[lmiller1990]

@kspackman Sorry no-one replied to your comment. I also missed this.

There is not really a great 1:1 migration path for that particular use case. The idea of separating findComponent and find are because the returned wrapper VueWrapper and DOMWrapper have pretty different APIs and usages.

You should still be able to chain findComponent of each other - not sure if this helps in your specific use case. Adding a ref or something might be the only way forward. You could also just do findAllComponents (returns an array) and access the instance you want like that (again not ideal, best work-around I came up with of the top of my head).

[lmiller1990]

I think we can merge this - most of these are not only implemented in VTU v2 now, but also back ported to v1 when they could be.

[posva]

@lmiller1990 yeah, we can merge this. I couldn't push to the branch so I will merge and rename the file locally

[dobromir-hristov]

Thanks!