Getting Started with Vitest | Hacker News Reader

Getting Started with Vitest

vuemastery.com

20 pointsrmason4 comments

It's a lovely article and great technology. I am just not so on board with testing the implementation details of such a component. Visual testing always feels off when done with these kinds of testing frameworks (jest, and vitest). 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? If I change the CSS of the class name to a totally different background colour, then this test will still pass yet the component is broken because it has the wrong style.

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.

> 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 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.

You could apply extra data props as hooks that describe certain states. This is the approach taken by Cypress.

E.g.

Then check for existence of the prop rather than CSS classes.

Reply on news.ycombinator.com