vue-test-utils: Using a non deprecated function should not print a deprecation warning

Version

1.0.0

Reproduction link

https://github.com/maxarndt/repro-vue-test-utils-deprecation-warning

Steps to reproduce

  1. Clone repro repo
  2. npm i
  3. npm test

What is expected?

Using a non deprecated function as .destroy() should not print deprecation warnings.

What is actually happening?

Using the above mentioned function prints a deprecation warning.


The implementation of .destroy() needs to be updated to use the successor of isVueInstance.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 29 (20 by maintainers)

Most upvoted comments

I was thinking about this a bit recently too. I think some of our deprecations make perfect sense, but this one a little bit too aggressive. The general idea was “don’t reinvent the wheel, leave it up to your test runner” where possible.

If you really enjoy this method, you could just add it back in yourself; import { Wrapper } fro '@vue/test-utils' and modify the prototype. We actually have a plugin system in V2 of this library to make it easier to add your own methods.

That said, we do have exists for v-if, having visible for v-show might not be the worst idea. I really like the parallel of v-if -> exists, v-show -> visible.

I think the other deprecations still make sense, though. I would like to get another opinion from @afontcu or @dobromir-hristov, and finally if anyone else is reading this and feels strong about porting visible from jest-dom to VTU, please thumbs up this.

If you’re here looking for a transition for [vue-test-utils]: isVisible is deprecated and will be removed in the next major version. Consider a custom matcher such as those provided in jest-dom: https://github.com/testing-library/jest-dom#tobevisible. When using with findComponent, access the DOM element with findComponent(Comp).element. Let me summary above comments and hope it could save you some time

// old assertion
expect(wrapper.find('.selector').isVisible()).toBeTruthy() // .toBe(true)

// new assertion
import '@testing-library/jest-dom' // leave it in the top of the file or in the test setup file
expect(wrapper.find('.selector').element).toBeVisible()

You should have @testing-library/jest-dom installed.

Right decision IMO 👍 When #1557 lands in the official docs, the transition should be smooth. Keep up the good work, guys.

Hi! Getting visibility right is harder than expected, and jest-dom is already doing a solid job. As @hiendv just said, we decided that focusing on Vue-related stuff was smarter than re-inventing the wheel 😃

Sounds good. I think we can all agree that the ultimate goal of this library and testing in general is to give you confidence in your application. If is enables you to be more confident in your application, we should include it 👍

@p0psicles no problem!

the deprecation messages are just that – deprecation messages. Your tests will keep doing fine for a while, you don’t need to worry about them right now!

That being said, jest-dom is framework-agnostic, so there’s nothing on it that makes it React-specific. After you install the library, its matchers become available so you can write expect(...).toBeVisible().

Hope this helps 🙌

This is fixed in the latest version (1.0.2). Try installing that one.

Lmk if any others come up. And yes, we should have had better tests around the deprecations. Focus has largely been elsewhere, mainly around Vue 3, but that’s no excuse. Let’s make sure we keep the standards high.

@lmiller1990 I believe we could close this one as relevant MRs were merged!

Oh, I see. If you have time it’d be great if you can make a PR improving that message. I will do a release soon.

Thanks @hiendv, I added your example to the migration docs.

Ah ok, .element makes sense, as I was confused why there was such an emphasis on finding components over DOM nodes before and now that thought has switched?

I’m okay with either, as long as I can write tests of course 😃

Thanks for the heads up, I will upgrade and update my tests.

Thanks I’ll give it a whirl in a bit to see if it’s resolved.

I appreciate all the hard work though, just found it odd that the internal build has these warnings suppressed on purpose, that seems to sort of defeat their purpose a bit 😉