setProps and setData error in beta.30 version

[woothu]

Version

1.0.0-beta.29

Reproduction link

https://github.com/coreui/coreui-vue/tree/bc1cf959325aee78d692e000184825c43294e158

Steps to reproduce

1. clone repo: https://github.com/coreui/coreui-vue/tree/bc1cf959325aee78d692e000184825c43294e158
2. npm i
3. npm run test (then all test passes)
4. update @vue-test-utils to beta.30
5. npm run test

What is expected?

beta.30 version doesn't break existing tests

What is actually happening?

beta.30 version breaks existing tests

---

In beta.29 all my tests are passing, after update to beta.30 many tests that are using "setProps" and "setData" methods are failing.

P.S. there is no possibility to chose beta.30 from versions in issue generator.

[hiendv]

I'm having the same problem with you. You can try using nextTick as a workaround.

[vvanpo]

@woothu this is expected behaviour, as beta.29 still had synchronous updates as the default behaviour, whereas beta.30 removes the option entirely and only allows asynchronous updates. This requires waiting for Vue.nextTick() or wrapper.vm.$nextTick() after triggering DOM changes.

Because this project is still in beta, there are no guarantees of backwards-compatibility between versions.

[DoubleWombat]

@vvanpo Moving from synchronous to asynchronous updates is a huge change, especially when users will not know why all their tests are now breaking. In my case it broke 56 of my 70 tests, so updating each test with Vue.nextTick() was not a good option. beta.30 also seems to be handling Vue transitions differently, causing further breaking tests. I have now learnt my lesson and limited my package.json to beta.29.

[vvanpo]

@DoubleWombat Yep, I can sympathize. It's an unfortunate outcome of a core Vue project being kept in beta while the rest of the Vue ecosystem has long had stable releases. Everyone is in the same boat, most will have to pin their version to beta.29 until they can find the time to update all of their tests (for example, at my work we have a project with over 2000 tests using @vue/test-utils, which all need to be migrated).

To aid in migration, you can update your test suites piecemeal by setting sync: false in the mounting options passed to mount() or shallowMount(). This ensures the tests are forwards-compatible, meaning once all your tests are written this way the upgrade to beta.30 should be seamless.

[stats94]

Is there a reason to completely remove the synchronous option? Is it just down to Vue itself? For tests it would be nice if there was an option I could force the state without having to wait for the next tick

[woothu]

@woothu this is expected behaviour, as beta.29 still had synchronous updates as the default behaviour, whereas beta.30 removes the option entirely and only allows asynchronous updates. This requires waiting for Vue.nextTick() or wrapper.vm.$nextTick() after triggering DOM changes.

Because this project is still in beta, there are no guarantees of backwards-compatibility between versions.

It would be nice if you mention breaking changes on release notes, especially as your tool is widely used on user's production environments.

[hiendv]

@woothu Actually they did. https://github.com/vuejs/vue-test-utils/blob/b7c546266b4f2756208ff9c39e5876c43fc36293/CHANGELOG.md#breaking-changes

[woothu]

I meant release notes https://github.com/vuejs/vue-test-utils/releases

[hiendv]

Oh I see. Maybe something wrong with the release process because the script looks fine https://github.com/vuejs/vue-test-utils/blob/dev/package.json#L21

[woothu]

Maybe it was set by setData method 😂

[vvanpo]

Is there a reason to completely remove the synchronous option? Is it just down to Vue itself? For tests it would be nice if there was an option I could force the state without having to wait for the next tick

@stats94 There is some background here: #1137

I agree that synchronous updates were very convenient, but it seems that maintaining a synchronous capability within Vue.js purely for testing was troublesome.

The benefit of always writing async tests is that you can be more confident that you are not overlooking subtle race conditions. Additionally, I think it can help programmers understand their components better, as it forces them to think about when DOM updates are triggered.

[tmorehouse]

We've encountered issues (after adding a nextTick wait after all set data/props and event triggers), but now the transition hooks afterLeave and afterEnter no longer fire (cannot be tested), no matter how many nextTicks or sleeps we do (this is without the transition stubs)

[hiendv]

@tmorehouse You can try to stub the transition component. It's much simpler than the old TransitionStub but it works for me. For TransitionGroup, I guess we can do the same.

stubs: {
  transition: {
    render: function (h) {
      return this.$options._renderChildren
    }
  }
}

Note: You still need to await wrapper.vm.$nextTick() though.