Explain what the replacement for deprecations are

[Wmaarts]

What problem does this feature solve?

The documentation for for example setMethods is unclear. It simply states: "setMethods is deprecated and will be removed in future releases.". Same goes for isVueInstance.

This does not explain what the replacement (if any) should be, or why this was deprecated.

These types of warnings also happens when running the tests:
"[vue-test-utils]: overwriting methods via the methods property is deprecated and will removed in the next major version"

Here it's also unclear what the fix should be or why this was deprecated.

What does the proposed API look like?

Not applicable.

[afontcu]

Hi! Thanks for filling this in.

There's no clear path to replace setMethods or methods property, because it really depends on your previous usage. It will be removed because it might lead to flaky tests – your tests end up relying on implementation details. The suggestion is to rethink those tests, I believe! (more on that on the VTU RFC).

Still, if you have some ideas of guidance/suggestions to help users, we'll be more than happy to review a PR! 😃

[jimmerydad]

For isVueInstance , if the note included at https://github.com/dobromir-hristov/rfcs/blob/vtu-2-api/active-rfcs/0000-vtu-api.md#isvueinstance

find always returns an DOMWrapper and findComponent returns a VueWrapper. Both return ErrorWrapper if failed.

were added it would have saved me a little time finding this as well (ie to use findComponent )

[nicojs]

The suggestion is to rethink those tests, I believe! (more on that on the VTU RFC).

Would be awesome if this is reflected in the deprecation warning. Maybe link to that page. Right now we get 100's of deprecation warnings without a clear path on how to fix them.

[afontcu]

Makes sense, thank you all for the suggestion. Anyone fancy to open up a PR with improved deprecation messages? 😇 otherwise I will.

cheers!

[mydnic]

I have the similar problem with isVueInstance
Exemple, I have a very small and basic test to assert that a component is correctly mounted without error.
For that I used expect(wrapper.isVueInstance()).toBeTruthy()

Now that I have the deprecation notice, I do not know how I can replace this basic test.

Any idea ?

Thanks a lot!

[mydnic]

Nevermind, looks like expect(wrapper.exists()).toBeTruthy() does the trick for me

[janosrusiczki]

I'm just plus one-ing the need to explain what to use to replace isVueInstance(). Else you'll probably have this issue pop up many times as many tutorials use this assertion as a basic example and it tends to stick in people's tests.

[lmiller1990]

For isVueInstance, tests. I would generally recommend just deleting those tests - it's just testing an implementation detail, which is not usually a good thing.

You could do expect(wrapper.find(...).vm).toBeTruthy() if you feel very strongly about keeping those tests. isVueInstance just called !!this.vm internally, anyway, as seen here.

setMethods is tricky, very much case by case! @afontcu is putting some docs together to help with this.

If anyone has a complicated test with setMethods that cannot wait, feel free to post it here or message me on Twitter or Discord (Vue-land) or email (in my GH profile) and I can help you.

If the deprecations messages are super annoying, you can temporarily silence them:

import { config } from `@vue/test-utils`

config.showDeprecationWarnings = false

[afontcu]

Hi folks! I'm pinging everyone on this issue because #1548 is up and we'd like to receive your feedback on the updated deprecation messages 😇

thanks!

[begueradj]

@afontcu
You said: "your tests end up relying on implementation details." but personally I do not see how using isVueInstance relies on implementation details.

[begueradj]

@lmiller1990
You said: it's just testing an implementation detail, which is not usually a good thing.

For isVueInstance, tests. I would generally recommend just deleting those tests - it's just testing an implementation detail, which is not usually a good thing.

You could do expect(wrapper.find(...).vm).toBeTruthy() if you feel very strongly about keeping those tests. isVueInstance just called !!this.vm internally, anyway, as seen here.

setMethods is tricky, very much case by case! @afontcu is putting some docs together to help with this.

If anyone has a complicated test with setMethods that cannot wait, feel free to post it here or message me on Twitter or Discord (Vue-land) or email (in my GH profile) and I can help you.

If the deprecations messages are super annoying, you can temporarily silence them:

import { config } from `@vue/test-utils`

config.showDeprecationWarnings = false

How come it is testing an implementation detail ? I do not see that, if you can explain, thank you

[lmiller1990]

Ideally you should test the input and output of the component (or any function in general, when writing tests).

For example, for a Vue component, the inputs might be a user filling out a form and submitting it, and the output might be the component renders a "Success" message. We don't really care how the component works, but that the behavior is correct.

Asserting that something is a Vue instance is not very useful and provides little value; it's much better practice to test the behavior.