2 ms·
The way I've always thought of it is that my unit tests have to be a level of complexity simpler than the code under test. Otherwise the "bugs" are equally like
by VBprogrammer 8y ago
The way I've always thought of it is that my unit tests have to be a level of complexity simpler than the code under test. Otherwise the "bugs" are equally likely to be in my test code as the production code.
I think he makes a very strong point that if the code is too complicated to use in tests then the production code should change. Simply because if it's hard to set up for you in tests; then it's almost impossible for someone else to use in real code. When they should be reusing your component they will give up and write a 'better' version for themselves.
- whack 8y agoI don't see how replacing a bunch of copy-pasted code with a helper method, makes your bug risk any greater. If anything, it reduces your bug risk because when you need to make changes everywhere, you won't miss out in a couple places by accident. Not to mention that the right abstractions will actually make your code simpler, instead of more complex. Imagine if someone needs to use an arraylist in a test, but decides to reimplement inline using arrays instead. Sure, they have avoided the use of a higher level abstraction, but the resulting code is now both harder to read and more likely to contain bugs.
- VBprogrammer 8y agoI think the point was to avoid the need for a bunch of copy paste by making the code simple to interact with in the first place. He isn't really advocating never using helper methods either. In fact he gives an example where the helper methods hide some irrelevant values. If I were to rephrase it as "repeated code isn't necessarily bad in tests" does that make it more palatable?