feat: Expose the component instance

[sarayourfriend]

Thanks for the awesome project! I've really enjoyed using it over at WordPress/Gutenberg and now introducing it to WordPress/openverse-frontend. It's been a great tool for learning and teaching people how to test with a focus on accessibility. Again, thanks so much!

I ran into this issue today so I decided to open a PR that would help me solve the issue, hope that's okay! This would also solve some of the issues found in this issue: #92

By exposing the vm from the @vue/test-utils wrapper, it'll allow doing things like calling Component.fetch.call(wrapper.vm) which is necessary becuase by default Vue doesn't call the "extra" Nuxt lifecycle methods (more about those here https://nuxtjs.org/docs/2.x/components-glossary/pages-fetch)

Maybe there's another more complex approach that would work more seamlessly (like adding a plugin that calls these methods for you or something) but this seems like the simplest option, just exposing the component instance that you'd get if you just used @vue/test-utils directly.

[sarayourfriend]

@afontcu would it be possible for you to take a look at this PR. Is it possible that this feature could be merged? It would help fix some issues with using testing-library and Nuxt that we've run into at Openverse.

[afontcu]

@afontcu would it be possible for you to take a look at this PR. Is it possible that this feature could be merged? It would help fix some issues with using testing-library and Nuxt that we've run into at Openverse.

Hi! And sorry for the late reply, busy weeks and holidays and so on :) And thank you for your kind words! It's great to hear you folks at Wordpress are using it. How humbling! 😄

I'm afraid this is unlikely to get merged as it kind of breaks two of the main principles for Vue Testing Lib:

1. Writing tests that resembled the way the software is used.
2. Have a symmetrical API with other testing-library flavours such as React – at least, as much as possible.

Sadly, by exposing vm we'd be kind of breaking both of them. I know (1) is not that clear here, as we're talking about setting up the right test env. However, exposing vm opens the door for a lot of arbitrary internal modifications of the component. That is, your use case is valid and hooking into Nuxt lifecycles might be sensible, but for instance one could also call private methods from vm

To solve your use case, maybe using the official Vue Test Utils library is a valid solution, as suggested in the linked issue? It exposes a myriad of options that would allow you to modify the vm while keeping Vue Testing Library closed to implementation details

That being said, if we find enough compelling cases for it we could reevaluate the situation and integrate some workaround.

[sarayourfriend]

@afontcu Okay, thanks for the thoughtful response. I kind of figured that might be what the answer would be 🙂 I'll close this PR and we'll continue to use the regular Vue Test Utils directly in these cases.

Thanks again for all your hard work!