Skip to content
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

VueTestUtils 2 API proposal for Vue 3 #161

merged 3 commits into from May 7, 2021


Copy link

@dobromir-hristov dobromir-hristov commented Apr 22, 2020


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.


@dobromir-hristov dobromir-hristov changed the title VTU 2 API proposal for Vue 3 VueTestUtils 2 API proposal for Vue 3 Apr 22, 2020
active-rfcs/ Outdated Show resolved Hide resolved
active-rfcs/ Outdated Show resolved Hide resolved

[Link]( - Moved to `global.mocks`

#### provide
Copy link

@xanf xanf Apr 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

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.

@posva posva added the final comments This RFC is in final comments period label May 14, 2020
Copy link

kspackman commented Jun 2, 2020

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:
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?

Copy link

lmiller1990 commented Jul 1, 2020

@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).

Copy link

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.

Copy link

posva commented May 7, 2021

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

Copy link
Contributor Author


@posva posva merged commit 3c2bb56 into vuejs:master May 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
final comments This RFC is in final comments period
None yet

Successfully merging this pull request may close these issues.

None yet

5 participants