DEV Community

Discussion on: Why practicing DRY in tests is bad for you

Collapse
 
skyboyer profile image
Yevhen Kozlov

I 100% agree that for complex tests the more local helpers are used, the harder debug/isolation gets. Similarly, having loops or conditions inside of test code(not "code under test") also makes it much harder to figure out what's going wrong when test fails.

But from the other side, for data-driven tests(no interaction simulated, just "input-output" check), test.each groups test cases in very natural way that test the same but for different edge conditions. And to debug them we can and will use conditional breakpoints. My rule of thumb(by experience, very subjective) for better readability: "max 3 inputs, only primitive values in input, single output to check, all inputs are listed in template for name in natural way, as if I would say what's going on out loud".

Similarly to snapshot testing, I think this approach really shines in quite limited set of conditions. But still can be used. Using example from article, name pattern ${first}+${second}=${expected} would give better readability then separate it("1+-1=0",...); it("1+Infinity=Infinity",....);...