The VueWrapper does not update by itself

[KalDev468]

Hi all

What we have ?

We have three element:

1. A button
2. A simple html element
3. A component

Scenario

When we click on the button, the element and the component are removed.

Tests

The first test:

• Check that the element exist in the beginning
• Click on the button
• Check that the element no longuer exist

The second test: (Same as the first but for the component)

• Check that the component exist in the beginning
• Click on the button
• Check that the component no longuer exist

Result

The first test works in both versions of VTU.
The second test only works in VTU but fail in VTU-next.

Problem

For the DomWrapper it is necessary to re-search the element to have its new state. this behavior is the same in both versions of VTU, so nothing changed.
But for the VueWrapper, in VTU, it was not necessary to re-search the component to have its new state, the wrapper updated itself. which is no longer the case in VTU-next. so this is the identified change

Debug

Difference between the two versions (after the action of the click, therefore after removing the element|component):

For DomWrappe: there is no difference, it is always necessary to redo a search to have the new state of the wrapper.

For VueWrapper: without redoing the search

VTU version/Method	exist()	html()
VTU(Vue 2)	false	HTML code
VTU-next(Vue 3)	true	TypeError: Cannot read property 'vue_app' of null

Questions

Is that the new behavior or is it a bug?
If this is the new VueWrapper behavior, do we need to re-search the component after every action or is there a better solution?

Code

import {mount} from "@vue/test-utils";

const componentA: any = {
    template: `<div>component</div>`
}

const app = {
    template: `
        <div>
            <button @click="isOpen = false">close</button>
            
            <!-- REMOVE AFTER CLICK ON THE BUTTON -->
            <div id="element" v-if="isOpen">element</div>
            <componentA v-if="isOpen"/>
        
        </div>
    `,
    components: {componentA},
    data() {
        return {isOpen: true}
    }
}

test('Element must not exist', async () => {
    let wrapper = mount(app);
    let buttonWrapper = wrapper.find('button');
    let elementWrapper = wrapper.find('#element');

    expect(elementWrapper.exists()).toBeTruthy();

    await buttonWrapper.trigger('click');

    elementWrapper = wrapper.find('#element'); // NECESSARY in both versions of VTU

    expect(elementWrapper.exists()).toBeFalsy();
});

test('Component must not exist', async () => {
    let wrapper = mount(app);
    let buttonWrapper = wrapper.find('button');
    let componentWrapper = wrapper.findComponent(componentA);

    expect(componentWrapper.exists()).toBeTruthy();

    await buttonWrapper.trigger('click');

    // componentWrapper = wrapper.findComponent(componentA);// NECESSARY ONLY IN VUT-NEST

    expect(componentWrapper.exists()).toBeFalsy();
});

[xanf]

I believe this is intended behavior in vtu-next. We're expecting you to always get a fresh VueWrapper. Otherwise we will be exposing too much specifics of Vue internals here :)

If you need "live" selectors it is quite easy to emulate them with Proxies in place

[KalDev468]

If this is the desired behavior then it is bad for people like me who have already written tests with the old behavior. it makes the tests fail and in addition it will increases the number of lines of code.

Can you please give me more indication about emulate with proxies ?

[lmiller1990]

I think we've had this problem before.

• findComponent helper returns different instances every time when called #286

Although this was how it worked in VTU v1, I think it was just a co-incidence and not something that was specifically designed. If there is some way to replicate that behavior here, it might be good to do so for backwards compat, but I think that would require access to unexposed Vue internals.

At this point, I don't plan to try and implement this - I'd recommend just re-querying. It's a bit of extra code, but likely makes your tests more reliable by not relying on mutation.

If you feel strongly about the original behavior, I'd welcome a PR exploring implementing it, but I suspect it will be very complex to do, and potentially break other behaviors. I don't have an intention to implement it in the immediate future, so your options are:

1. Update your tests.
2. Implement this behavior in VTU v2.

[lmiller1990]

I think we cannot make this change - since Vue is using a vdom anyway, better not to rely on raw DOM references where possible. Instead, re-query to get the latest wrapper.

I'm sorry this was an unintended breaking change, I hope this won't be too disruptive. I don't think it's practical to implement the requested feature here without introducing new bugs or regressions.

[cexbrayat]

@lmiller1990 Yeah I agree. It does force developers to update a few tests when migrating but I think it's for the best. Let's close this one