The article title is going to get people to summary judge without reading.<p>The actual article is a nice exploration of prioritizing unit tests based on context-driven testing principles: the decision-making around how to concentrate tests on your codebase in areas that need it, while not getting hung up on dogmatically creating them for areas that are already stable enough.
I was on board for points 1 and 2, but completely disagree with 3:<p>> The components might look wrong when rendered. Tests are very bad at this. We don't want to go down the esoteric and labor-intensive path of automated image capture and image diffing.<p>This is <i>the</i> main reason we have tests for our (Angular) typescript all; all the tests roughly look like:<p>1. set up component with fake data<p>2. take screenshot and compare with golden<p>3. (maybe) interact with component and verify change<p>These are super easy to write, and also easy to review: most review comments are on the screenshots anyways. And since the goldens are checked in, it’s easy to see what different parts of the app look like without starting it up.
I agree with this sentiment; I try to not test anything that renders. I don't want to test React's correct handling of the DOM and I don't want tests that fail if someone changes a div to a span. The stuff I'm looking to test tends to be the code that naturally feels like it belongs in a helper function.
Anyone have experience with <a href="https://www.chromaticqa.com/" rel="nofollow">https://www.chromaticqa.com/</a><p>Seems like a great solution