Getting Started with Vitest(vuemastery.com)
vuemastery.com
Getting Started with Vitest
https://www.vuemastery.com/blog/getting-started-with-vitest/
5 comments
> As in do you really want to test that a class name is applied to assert that the component rendered with a certain style or visual look?
I think the author doesn't do a good job in explaining what questions such tests are helping to answer. By checking the class name of an element in a component, you are not testing the visual appearance of the component, but its behavior. As in, given a certain set of inputs, the component is expected to produce a certain output. In the author's example, the difference in component's behavior when it receives different `type` props ("success"/"error"/"info") is that it produces a DOM element with different class names. It doesn't tell you anything about whether the component looks right on the screen, but it does confirm that the component is responding to the `type` prop correctly.
I think the author doesn't do a good job in explaining what questions such tests are helping to answer. By checking the class name of an element in a component, you are not testing the visual appearance of the component, but its behavior. As in, given a certain set of inputs, the component is expected to produce a certain output. In the author's example, the difference in component's behavior when it receives different `type` props ("success"/"error"/"info") is that it produces a DOM element with different class names. It doesn't tell you anything about whether the component looks right on the screen, but it does confirm that the component is responding to the `type` prop correctly.
I guess another way to put it: how much value does this test provide? Maybe an extreme opinion but I am totally okay with removing tests of little value. Tests require maintenance and attention, so is the test itself a net negative on the codebase? Just because you have a test for a component, it doesn't necessarily mean that the test is valuable. Testing for the sake of testing isn't a great idea.
That being said, I understand what the test is doing also thanks to your explanation! My point is if you refactor the internal behaviour, the implementation details, then a good test would not need to be changed either. As in I want to keep the same look and design of the component, now with say different styles or maybe I dropped in a component from our UI library.. now there are no classnames but visually it's the same. So if I change the internal behaviour, the end result should be the same and the test shouldn't need to change.
That being said, I understand what the test is doing also thanks to your explanation! My point is if you refactor the internal behaviour, the implementation details, then a good test would not need to be changed either. As in I want to keep the same look and design of the component, now with say different styles or maybe I dropped in a component from our UI library.. now there are no classnames but visually it's the same. So if I change the internal behaviour, the end result should be the same and the test shouldn't need to change.
You could apply extra data props as hooks that describe certain states. This is the approach taken by Cypress.
E.g.
<div data-state=“success”>
Then check for existence of the prop rather than CSS classes.
E.g.
<div data-state=“success”>
Then check for existence of the prop rather than CSS classes.
Although then I have to answer the question, what is the best way to test for visual changes? Then it would have to be visual snapshots where you save the current state of the test as a screenshot and then assert it matches the previous run.