Currently I am working on a Vue component library which can use some testing. Since Vue components always form a wonderful mix of JS, HTML and CSS it is harder to me to think about testing them the way I would in PHP.
Because in PHP I often can use a very clear cut setup of testing the public functions of a class and can easily mock out the dependecies by injections. I can quite easily hold on to the concept of Unit testing as a basis for my tests.
In Vue components I believe all I should do is consider all my work to be intergration testing rather then unit testing. My main arguments for this are:
- My templating logic, like the
v-ifandv-for, heavily define the logical paths and can't be turned into seperate units/functions. - My JS logic should not be turned into seperate files or composables just for testing purposes if it is more logical or practical to keep it in the component. what I consider logical or practical reasons to seperate code is when you want to use it in at least two places or when you can keep a better overview of what is happing in the component.
To me it becomes easier to reason about all my components as intergration tests, that at the very least combine three languages and in most cases also include dependencies in JS in the form of packages, composables or child components.
This thinking makes it easier for me to review my code prior to writing tests. I now skim them for what I would consider a Unit and then write a few tests per Unit in a intregration testsuite instead of pulling apart a nice component and testing every function.
What I consider a Unit is more then the specific function or () => we use in JS. Every logical fork can be considered a Unit and I just make a educated guess about which of those forks are important. If I have a v-if on a prop boolean that shows or hides text I tend not to test it, because by reading the code I am already a 100% certain it will work. But if I have a v-if that if the boolean is true is depended on other props to exist to show an output I am more likely to test it.
Basically I try to look for "meaningful intersections" within all the logical paths that exist in my code.
Does my reasoning make sense to you? Or do you believe I am wrong in thinking that components should always be viewed as intergration tests? I would like to hear a different take on the topic.
Top comments (1)
I believe component should be viewed as integration test.
Unit tests don't fit very well on this world. Plus, with typescript and eslint you're quite covered on those potential bugs. If I need to write unit tests, I mostly get the edge cases covered.
I like to have unit tests on small utils functions, for example.
Regarding components, it's good to test how they perform on different props as you said.
This article can be useful kentcdodds.com/blog/write-tests