v1.1.4 regression

[Ky6uk]

Subject of the issue

After upgrading from v1.1.3 to v1.1.4 some tests have started to fail.

Steps to reproduce

const wrapper = mount(MyComponent, {
  propsData: {
    items: [
      { name: 'woof' },
      { name: 'bork' }
    ]
  }
});

const items = wrapper.findAllComponents({ name: 'MyComponentItem' });
const firstItem = wrapper.at(0);
//                           ^--- [vue-test-utils]: no item exists at 0

// ...

Expected behaviour

Tests should pass as it was before the upgrade.

Actual behaviour

Tests failed.

Possible Solution

Downgrade to v1.1.3.

[Bastczuak]

Here's another example for a failing test after upgrading to 1.1.4

import SupportFaq from '@/views/SupportFaq'
import { routes } from '@/router'

jest.mock('@/views/SupportFaq.vue', () => ({
  name: 'SupportFaq',
  render: h => h('div'),
}))

it('works in 1.1.3 fails in 1.1.4', async () => {
  const router = new VueRouter({ routes })
  const localVue = createLocalVue()
  localVue.use(VueRouter)
  const wrapper = mount(
    {
      template: '<router-view/>',
    },
    {
      localVue,
      router,
    },
  )

  await router.push('/support/faq')

  expect(wrapper.findComponent(SupportFaq).exists()).toBe(true)
})

[lmiller1990]

Interesting, what on earth would have caused this I wonder.

[lmiller1990]

Actually, no I don't wonder, I bet it is this: #1817

I cannot look few a few days, if someone wants to try reverting that commit and see if that's the problem? This seems like it's pretty important to fix and patch asap.

[Bastczuak]

@lmiller1990 reverting these two changes in 1.1.4 fixes my problem with the posted example above. The change in line 59-65 in matches.js breaks my test.

[lmiller1990]

If we just revert it, we will break the issue it was trying to fix. What I think we should do is

1. add an example that fails dud to the regression to the specs in this code base
2. put back the code that makes it pass
3. make sure this example case continues to pass

Are you interested in making this change?

[Bastczuak]

@lmiller1990 I'll give it a try.

[Bastczuak]

@lmiller1990 I can't reproduce the error. I wrote a test #1832 like @Ky6uk posted. Unfortunately the test succeeds. I used his example because mine is more complex. Maybe I miss something.

[BeeMargarida]

I confirm, could not reproduce a failing test with both the examples provided in this issue. I'm not sure if all information was provided in them for us to be able to reproduce

[Bastczuak]

Ok I was able to create a failing test in #1832 depending on my posted example! I added some comments because I encountered some problems. Please have a look @BeeMargarida. I still have no clue what causes it.

[BeeMargarida]

@Bastczuak I think this is another problem not related to the changes made in #1817, even with the regression the test continues to fail (only with shallowMount)...hum. If I'm understanding this correctly 😅

[Bastczuak]

@BeeMargarida Yes, but that should be normal behaviour because shallowMount stubs the <router-view/>. I describe this in the added code comments. I don't know how to unstub <router-view/> using shallowMount.

[BeeMargarida]

@Bastczuak Yes, you are right 😄
With the test you wrote, I wrapped it with the itDoNotRunIf and it ignores shallowMount, like so:

itDoNotRunIf(
    mountingMethod.name === 'shallowMount',
    'returns a VueWrapper instance by CSS selector if the element binds a Vue instance',
    async () => {
        ....
    }
)

So, I think I found the problem. The "old" logic checked if the selector was functional and, if not, used the node.child. In your test-case, the component is not functional, and in the "old" logic, it would end up using node.child. However, with the "new" logic, it will default to the functionalOptions if they are defined. In the router use case, it is defined, but is pointing to the RouterView. Problem: when entering vmCtorMatches,the node.child contains the extendOptions that match with the wanted selector, which the functionalOptions of the node RouterView does not contain (since its not this node we want to compare to).

So, for this use case, we need the child, but for the test made in the other PR we need the functionalOptions. I don't know enough to know how can we distinct between functional nodes and the RouterView node.

("new" logic with the test case created by @Bastczuak, in this case the _Ctor won't have the extendedOptions` that match the selector)

TLDR: when using the RouterView node, we want to use the node.child in the matches, however in the functional components, we want the inverse. The current logic will always default to the functionalOptions of the routerview node instead of this child.

[leungk712]

Hello, would this by chance have affected v1.1.1? At my job, we've had router tests that have passed for 7-8 months until this past week where things have just failed out of nowhere. We haven't even touched the codebase either within the past 2 weeks.

[lmiller1990]

@leungk712 no, this was introduced in 1.1.4 according to the bug report. You must have changed something (updating the dependencies?)

Regarding " I don't know how to unstub using shallowMount" - you can't, it's shallowMount. The point is to stub all the things.

@BeeMargarida great investigation. Is there any reason we cannot just revert to the previous logic, then add in the additional code that was added in the PR that caused this regression? That (should) cover all the cases (I think... the shallowMount and findComponent logic is so complicated, I would need to re-familiarize myself with it).