4 ms·
We actually ran into this as a problem: our tests were so DRY that it was really hard to adapt them as the behaviour of our application changed. We've since go
by jonasvp 10y ago
We actually ran into this as a problem: our tests were so DRY that it was really hard to adapt them as the behaviour of our application changed.
We've since gone more DAMP (http://stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests http://stackoverflow.com/questions/6453235/what-does-damp-no...): tests should be descriptive and meaningful by themselves, not abstract, concise and DRY.
It makes for more lines of test code but they are simpler to understand and adapt.
- aisofteng 10y agoWhen you abstract away test code, you are abstracting code written to test a software application's design, and thus your abstractions (and test data) necessarily mirror your application design. This is why I commented elsewhere that DRY should be applied not as a coding principle to all code, but as a design principle to software design.