v-if inside transition element not re rendering in beta30

[aldarund]

Version

1.0.0-beta.30

Reproduction link

https://github.com/aldarund/vue-test-utils-transition-bug

Steps to reproduce

components/test.test.js
When changing rendering v-if of element inside transition and do nextTick/flushPromises vue test utils still renders old version.
Tried with flush-promises too, same effect.
Relevant files only following

components\TransitionTest.vue
components\test.test.js

all other just stub files from empty project create.

What is expected?

test is passed

What is actually happening?

test is failing

---

If change version to v29 all works fine. Without wrapping into transition all works too

[lmiller1990]

A lot of things broke relating to transitions in beta 30. There is a work around that might help documented here: https://vue-test-utils.vuejs.org/guides/#common-tips (under "Mocking transitions") however this is a bug we will fix before v1.0

I will try to look into this one in the new year.

[aldarund]

Thanks, workaround worked. Didnt saw this section of guide, since it was added only in v30 :)

[aldarund]

why close since its valid issue that is supposed to be fixed before v1 ? Is there other issue that could be tracked to see when its solved?

[JessicaSachs]

Whoops! I misread this. My apologies. Thank you for pinging on the issue

[mjhea0]

I don't believe this is isolated to just the transition element. I'm seeing the same issue with v-if when using wrapper.setData in the test.

Re-writing the tests to not use setData fixed it.

Begs the question: does setData no longer work correctly?

Example.vue:

<template>
  <div>
      <p v-if="show">Foo</p>
  </div>
</template>

<script>
export default {
  data() {
    return {
      show: true
    }
  }
}
</script>

Spec:

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

import Example from './Example.vue';



test("should render Foo, then hide it", () => {
  const wrapper = mount(Example)
  expect(wrapper.text()).toMatch(/Foo/)

  wrapper.setData({
    show: false
  })
  wrapper.vm.$nextTick()

  expect(wrapper.text()).not.toMatch(/Foo/)
})

It passes just fine with "@vue/test-utils": "1.0.0-beta.29".

[dobromir-hristov]

You need to "await " that tick.

[mjhea0]

You need to "await " that tick.

I thought the same thing; however:

1. It works without async/await in @vue/test-utils": "1.0.0-beta.29
2. It still breaks with async/await in @vue/test-utils": "1.0.0-beta.30

[mjhea0]

It's also passing in @vue/test-utils": "1.0.0-beta.29 without wrapper.vm.$nextTick().

[mjhea0]

I think I see what's going on here. The removal of the synchronous mode in 1.0.0-beta.30 is causing it to break now without async/await. It's not waiting in the above code, so it's introducing a race condition which just so happens to still pass in 1.0.0-beta.29

That still doesn't explain why it's breaking with async/await when 1.0.0-beta.30 is used, though.

[lmiller1990]

I just tried the code you provided with beta-30 with async/await and it worked fine for me:

<template>
  <div>
      <p v-if="show">Foo</p>
  </div>
</template>

<script>
export default {
  data() {
    return {
      show: true
    }
  }
}
</script>

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

import Example from '@/components/HelloWorld.vue';

test("should render Foo, then hide it", async () => {
  const wrapper = mount(Example)
  expect(wrapper.text()).toMatch(/Foo/)

  wrapper.setData({
    show: false
  })
  await wrapper.vm.$nextTick()

  expect(wrapper.text()).not.toMatch(/Foo/)
})

[lmiller1990]

As expected, stubbing the transition lets this pass:

stubs: {
  'VScrollXTransition': true
}

I think we should automatically stub all transitions in VTU. They are used for animations and that sort of thing, nothing you would actually want to need to test in a unit test.

Users could opt out with:

stubs: {
  transition: false, // or
  'VScrollXTransition': false // or something like this
}

It looks like Vuetify just wraps Vue's <transition> and <transition-group> components, so I think it would not be that difficult to implement.

I'll see what the rest of the teams thinks, and go for that unless someone has something better. I think fixing the transition bugs will close off a few other issues that are open, too.