9 ms·

Disagree :) In my experience, test code that has duplication everywhere makes it harder to reliably change the code under test, as there are so many tests that

Disagree :) In my experience, test code that has duplication everywhere makes it harder to reliably change the code under test, as there are so many tests that have to be rewritten and you're basically guaranteed to fuck something up. I'm not arguing for making the test cases harder to read, it's very important to be able to see input/output/expected output as always, but it's also important that you're able to change the test code confidently, and duplication actively works against that. I guess the "truth" or "optimal state" is somewhere in-between. Not 100% duplication but also not 0% abstractions.

piva00 3y ago
> I guess the "truth" or "optimal state" is somewhere in-between. Not 100% duplication but also not 0% abstractions. Exactly, I've seen way too much test code that abstracted away a fundamental piece needed for understanding the test setup, which made it much harder to reason about when tests failed. Jumping through the test to the utility used to avoid duplication is another layer of cognitive load, I'm already trying to troubleshoot something, I don't need more things to keep track of while I'm in that process. Rewriting test code is exactly the moment you take to abstract some of it away, when it's been proven that the pattern repeats and is annoying to rewrite. The usual rule of 3 of software engineering. > it's also important that you're able to change the test code confidently, and duplication actively works against that. I disagree with this point a little, if the tests are well written (even if verbose) it should be easy to reconfigure/rewrite them, even with dozens of test cases, it might take a bit more time to rewrite those than just changing a supplier/utility method but it has helped me a lot to actually read the tests. I've been burnt too many times by someone abstracting away the actual call (or a part of it) to the logic under test into an utility to "avoid duplication", that call is the whole point of the test case. One should be able to understand every test case easily so rewriting to accommodate the change made should be straightforward, if it's not then the test case itself is telling there's a code smell, either in the test or in what is under test. The more egregious to me is when tests are a mess of setups not following a simple, straightforward structure. It becomes hard to reason and change over time when the inevitability of growing code happens. Duplication or not won't be the main issue, the structure itself will. I will abstract away some complex setup/adjacent code that isn't under test but anything that the test cases might interact with, and fail because of it I do prefer to be extremely explicit and duplicate code instead of trying to make my tests look tidy and neat.
- capableweb 3y ago
  A mantra I usually follow is "If you're putting something under 'utility'/'utilities'/similar names, you're cheating on your design and you're only putting it there because you can't figure out a better place, think longer/harder.". Applies equally for testing code :)

piva00 3y ago

> I guess the "truth" or "optimal state" is somewhere in-between. Not 100% duplication but also not 0% abstractions. Exactly, I've seen way too much test code that abstracted away a fundamental piece needed for understanding the test setup, which made it much harder to reason about when tests failed. Jumping through the test to the utility used to avoid duplication is another layer of cognitive load, I'm already trying to troubleshoot something, I don't need more things to keep track of while I'm in that process. Rewriting test code is exactly the moment you take to abstract some of it away, when it's been proven that the pattern repeats and is annoying to rewrite. The usual rule of 3 of software engineering. > it's also important that you're able to change the test code confidently, and duplication actively works against that. I disagree with this point a little, if the tests are well written (even if verbose) it should be easy to reconfigure/rewrite them, even with dozens of test cases, it might take a bit more time to rewrite those than just changing a supplier/utility method but it has helped me a lot to actually read the tests. I've been burnt too many times by someone abstracting away the actual call (or a part of it) to the logic under test into an utility to "avoid duplication", that call is the whole point of the test case. One should be able to understand every test case easily so rewriting to accommodate the change made should be straightforward, if it's not then the test case itself is telling there's a code smell, either in the test or in what is under test. The more egregious to me is when tests are a mess of setups not following a simple, straightforward structure. It becomes hard to reason and change over time when the inevitability of growing code happens. Duplication or not won't be the main issue, the structure itself will. I will abstract away some complex setup/adjacent code that isn't under test but anything that the test cases might interact with, and fail because of it I do prefer to be extremely explicit and duplicate code instead of trying to make my tests look tidy and neat.

capableweb 3y ago
A mantra I usually follow is "If you're putting something under 'utility'/'utilities'/similar names, you're cheating on your design and you're only putting it there because you can't figure out a better place, think longer/harder.". Applies equally for testing code :)