Hacker News new | ask | show | jobs
by jrabone 4960 days ago
Until someone comes to do major rework and your tests take ten times longer to change than the code. It happens - a lot. Badly structured tests are worse than no tests to the extent that it's often cheaper to throw the lot away and write new tests - turning what should have been a simple "change the class hierarchy without changing the public interface" into "oh god every single test relied on the detail of the class hierarchy". No, they SHOULDN'T have. But they DID. And I get to fix it. Again. A particular anti-pattern I am observing right now is the "immutable interface, mutable implementation" approach. Every single test in 6 different sub-projects appears to want to create "special snowflakes" for testing, but was written to mutate an implementation which no longer exists. Days of extra work needed to figure out what the intent of the test was (no comments, because tests are self documenting, right? Sure they are.) and then re-write it using builder interfaces in the hope that this will save some poor sod (probably me) the trouble the second/third/fourth rewrite.

Be a better damn developer. Tests don't deserve cut and paste hell any more than your actual production does.