Feature request: stubs to contain events and props

[steven-twerdochlib]

Is your feature request related to a problem? Please describe.

It would be great to be able to test custom components from the template area while stubbed. For example, lets say I have the following: <customComponent @click="runRandomMethod" class="randomClass"><\customComponet> in my class and customComponent.vue has a bunch of properties, mapGetters and methods. I don't care about the required props in another class or the methods so I would shallowMount it but the issue with this is I can't find the component to trigger a click event that would run "runRandomMethod()". Let me know if anything I said is confusion I would be happy to elaborate. Describe the solution you'd like

I think it would be nice to somehow keep the events (things that start with @) and keep the props we send (things that start with :) and anything else like class so that we can test if another user accidentally changes something important there e.g. mispelling runRandomMethod. Let me know if anything I said is confusion I would be happy to elaborate.

Describe alternatives you've considered

I know you can make a custom component with that info but this wouldn't test if the user accidentally changes something as it would be a copy and paste of the customComponent rather than a reference to it.

Additional context

I'm using latest vitest version btw.

[cexbrayat]

Hi @steven-twerdochlib

I think in that case you want to use a custom stub instead of shallowMount.

We can't do much to automatically check that there are no mistakes in function names in VTU. If you care about this, I strongly encourage you to use TypeScript and vue-tsc which are designed for this and will catch these errors. I hope that helps!

[steven-twerdochlib]

Hi @cexbrayat, Thanks for the response, as I said a custom stub won't really work because (as far as I know) I would have to copy and paste <customComponent @click="runRandomMethod" class="randomClass"><\customComponet> from the .vue file to the .spec.js file to create it. This would mean any changes in the .vue class for this tag won't be automatically changed in the unit-test and so the test will continue to pass despite the intention is for it to now fail.

Currently shallowMount turns <customComponent @click="runRandomMethod" class="randomClass"><\customComponet> into something like <customComponent-stub><\customComponet-stub>. What I'm suggesting is a new kinda shallowMount so it will turn it into <customComponent-stub @click="runRandomMethod" class="randomClass"><\customComponet-stub>. Another way of looking at it is to do a mount but remove all info from the child class like methods and props and even template except for what makes it run.

Do you get what I mean?

[cexbrayat]

I understand, but I think this would be a hacky feature to add and maintain in VTU for a limited use case. Our teams use custom stub in that case, and it's not really hard to update them when the corresponding component changes to be honest.

[steven-twerdochlib]

Hi @cexbrayat,

Thanks for the reply and I do see what your saying, just some small points I want to get across before we shut down my feature idea:

I wouldn't say this is a limited use case :P. It's allowing the ability for unit tests to directly test components have been changed without using "mount". Besides the examples I've given previously, there's also testing class values have changed, disabled properties have changed, v-if inside customComponents tag are correct. Basically a lot of the stuff you would test for "mount" but without all the unnecessary child component info which would've been required for it to just run.

You are definitely correct that a workaround is creating a custom stub and copying and pasting frequently, I just suggested this as a new feature because my suggestion would be automatic and save time for creating stubs and/or filling in those required info for "mount" and well us programmers like automatic and time saving stratagies. One of the main reasons for unit tests is it's quick and automatic testing of desired features. It is also a lot more realistic to the expected user experience (midway between shallowMount and mount)

I understand if this is too much hassle to make and maintain but I like to think it would be an improvement to VTU if time permitting.