vuejs / rfcs

RFCs for substantial changes / feature additions to Vue core
4.87k stars 546 forks source link

VueTestUtils 2 API proposal for Vue 3 #161

Closed dobromir-hristov closed 3 years ago

dobromir-hristov commented 4 years ago

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.

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

Rendered

dobromir-hristov commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

dobromir-hristov commented 3 years ago

Thanks!