3 ms·
It's interesting that the author sees helpers and abstractions as being uniformly opposed to simplicity. If that's the case, why use helpers or abstractions in
by whack 8y ago
It's interesting that the author sees helpers and abstractions as being uniformly opposed to simplicity. If that's the case, why use helpers or abstractions in our production code either? Why not apply the author's advice in production code as well?
Badly designed helpers and abstractions are certainly ... bad. But well designed helpers and abstractions make the code much simpler to read, understand and maintain. That's their entire purpose.
There's certainly a lot of badly designed abstractions out there. If you come across one that makes the code harder to understand and maintain, you should certainly get rid of it and inline it instead. Regardless of whether it's production or test code. The flip side of this is that if you see an opportunity for abstractions that make the code easier to understand and maintain, you should certainly use it, even in test code.
- UncleMeat 8y agoIn production code a helper lets you reduce duplication, making refactoring easier and reducing bugs. It also adds additional test interfaces that can make code more reliable. Finally, it makes code more readable. But for tests you are optimizing for a different thing. You want to know what the input to the test is. This makes referring to the test as documentation much easier. Helper functions can work in tests but often they are completely opaque and make tests hard to understand.
- VBprogrammer 8y agoThe 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?