SFC with <script setup> and testing

[einavk]

Hi All,

I decided to get a hang of the new <script setup> way of writing in composition API, so I chose one of my project's components, and converted it (from options API).

When I was done, I went a head to fix the related jest tests of that component.

I then realized that in order to be able to test it fully, I need to expose just about anything using useExpose().

Moreover, I had to rewrite all the "computed" tests as they used the "call" and not the "mount" way of testing.

1. Is there a better way to test computed fields or do I have to "mount" and manipulate component and store data everytime ?
2. It seems wrong to me, that I have to change my code and "expose" just so I can test it. I know everything about the component was exposed by default in the past, and that this new way gives me more control - but if at the end I have to expose it all anyway, it feels like a weird overhead to have (assuming that you are testing all your files). Have I missed anything here?

Thanks,
Einav

[jacekkarczmarczyk]

By testing computeds etc you're testing internal implementation. You should test component's public API instead and that does not require exposing anything (unless you want to add public methods to the component's public API).
If you want to test the business logic of your computeds you can create an es module that exports the function doing the calculations, use this function in the computed and test the function itself

[einavk]

Hi,
Thanks for your response.

What do you consider to be the "public API" in a case of a component that no other component needs to $ref and use a direct function?
Would that only be the template ?

[jacekkarczmarczyk]

Template and events, not sure if there's anything else

[LinusBorg]

Template and events, not sure if there's anything else

Those are the most important, regular ones. props are the inputs of the unit, template and events are the output.

If you use stores, router etc then side-effects caused with those (i.e. route navigations) may also be considered

[jacekkarczmarczyk]

There's also provide/inject, for example component may want to call the provided function or update provided data

[einavk]

Ok, thank you both.
I understand your PoV.

I think this is sort of an "inferred" testing of the business logic of the component by the outcome in the template / events.

I'm concerned that using this approach alone, it is much easier to miss some scenarios in your testing.
Meaning, it should probably be complemented by the second suggestion by @jacekkarczmarczyk which was creating an es module that exports the function doing the calculations, and then testing it separately. That might be less maintainable (readability, finding your way around it, etc.) and should be done with caution and where makes sense.