Mech Retriever Dev Blog
I’ve done recent work to improve more test structure for Mech Retriever. A lot of people struggle with Test Code, for a variety of reasons, but one reason it’s such a chore for many is just how much repetition can creep in if you aren’t careful.
Some people advocate against “DRY” (do not repeat yourself) in unit tests, because they have seen efforts to reduce duplication cause problems where the tests were brittle and coupled to each other. I boldly proclaim their objection is wrong and misguided, because they don’t realize what they’re really objecting to–lack of adherence to the Single Responsibility Principle.
You should build a testing language–a second system, who’s purpose is to test the primary system you’re building. That means clean, decoupled, and refactored test code. The problem comes when people start making god-class test helpers, that all the tests rely on for everything. This is a problem because you end up with one big, tangled, terrible mass of code.
The thing is… YOU SHOULDN’T MAKE CODE LIKE THAT ANYWAY, IN TESTS OR OTHERWISE. Avoiding duplication isn’t the problem here–it’s failure to apply Object-Oriented coding principles to test code, just as you would “real” code. The phrase I’m fond of using is that “classes should be silver bullets, not swiss-army knives.”
May you build the ultimate giant robot.