findComponent doesn't work as expected after upgrade to 2.0.0-beta.5 for use with Vue 3

[buffpojken]

Subject of the issue

Previously passing tests now fail.

Steps to reproduce

The following test setup:

    const wrapper = mount(Conversation, {global: {plugins: [store], mocks: {$route}, mixins: [mixins]},  propsData: {ticket_id: 1}})
    await flushPromises()
    let conversation = wrapper.findComponent(Conversation)
    let textInput = conversation.find('textarea')

results in an error Cannot call find on an empty VueWrapper. even though the component was just mounted. This occurs even with the following Conversation.vue:

<template>
  <div class="page conversation">
    
  </div>
</template>

This feature works as expected post-migration to vue3, but the tests fail on this.

Expected behaviour

That findComponent should find the mounted component.

Actual behaviour

findComponent returns an empty VueWrapper.

Possible Solution

I've tried simplifying the components, but the problem still persists.

[lmiller1990]

I transferred this to vue-test-utils-next.

Can you please post your entire component and test (and ideally a repository of some sort). It is difficult to fix abug without a reproduction.

Based on your above info, are you trying to find a component in itself? Or does <Conversation> render another <Conversation>?

[buffpojken]

Sure thing, I'll wrap up a test repo.

No, <Conversation> does not render another <Conversation>. But in previous versions, mounting a component using mount() and then finding the root-component worked just fine? Based on your question - is that no longer the case?

For example, the following used to work just fine:

const wrapper = mount(Conversation, {global: {plugins: [store], mocks: {$route}, mixins: [mixins]},  propsData: {ticket_id: 1}})
let conversation = wrapper.findComponent(Conversation)
let textInput = conversation.find('textarea')
textInput.setValue('monkey')
expect(conversation.vm.pendingMessage).toEqual('monkey')

where pendingMessage is a v-model-backed data-attribute on <Conversation>.

Is this no longer supported? If not, how do one get access to the root-component when using mount()?

[buffpojken]

The reason I’m asking is that saw just now that vm also seems to have been removed from wrapper.

[lmiller1990]

vm still exists. If this worked in v1, we should support it here, too. It is probably an unintended breaking change.

If it's the root component, can't you just do wrapper.vm, though? vm certainly still exists.

[buffpojken]

Hmm, I see - can I open an issue or make a PR to add it the docs then? It's removed from the wrapper section in the reference.

I've put together a repo with a test case that passes with a set of previous versions of dependencies (basically [email protected] with test-utils and jest), but when updating to Vue@3 and [email protected] fails. The repo can be found here:
https://github.com/buffpojken/failing-vue-test-utils-case

[lmiller1990]

Sure! docs repo is here: https://github.com/vuejs/vue-test-utils-next please add vm to the docs!

I will investigate fixing this bug.

[lmiller1990]

Kind of fixed... #214

You will need to a name key to the component - I can't see any way to get this to work, otherwise. We will need to add this to the migration notes. This is quite a weird one - is there a specific use case where you want to find the root component?

[buffpojken]

To be perfectly honest, I'm not sure. I can't recall why we wrote these tests the way they are written, and can't definitely say that they weren't refactored into the current state.

That being said, backwards-compatibility wise there's a difference here.

Thanks for the fix though!

[lmiller1990]

There sure is a difference. I think if we can either make it 100% back-compat, that's ideal. If not, I think that's fine too, as long as we provide a migration guide (in this case, add a name or another alternative).

Posting this issue helped find the bug - which is great. I'll merge what we have for now, do a release, and keep thinking about how to get this to work in a 100% back compat way (if that's possible).