[azangru]

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

[testingwaters4]

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.