3 ms·

Got to quibble with Antipattern #9 about test code - there's certainly a place for extracting common patterns from test code (factories, complex setup) but too

Got to quibble with Antipattern #9 about test code - there's certainly a place for extracting common patterns from test code (factories, complex setup) but too much DRY in tests can make for hard-to-modify spaghetti. Sometimes it's easier to just repeat a few lines of code in the name of clarity.

diggan 9y ago
Sure, the point is to treat test-code as "normal" production code. The things you mentioned here applies for that code as well.
arthurdenture 9y ago
Similarly, overly elaborate test code can itself be buggy. A specific instance of this anti-pattern is when the test code duplicates the same logic as the code under test, logic which turns out to be incorrect. In test code, I am a lot more tolerant of straight-line repetition in the name of simplicity, in a manner that would be worth abstracting were it in non-test-code.
- rdiddly 9y ago
  That's a sign that you need to write tests to test your tests. It's part of treating your test code as a first-class citizen. I always write a test suite for my test suite. Just kidding.
  - squeaky-clean 9y ago
    I know this is a joke, but I do have a few "don't panic" tests that do extremely simple stuff, like just run a test and return True immediately, connect to db, connect to mock db, etc. Sometimes I do something stupid like put an extra comma somewhere without noticing, or update my db driver library without also updating my mock library. I think we've all had that moment where tests fail or it doesn't compile because you thought you copy-pasted some text into an email, but it got pasted into your editor window. So when I see that literally every test has failed, I know it was some really dumb but likely simple mistake on my part. If 180/195 tests pass.... Shit.
scaryclam 9y ago
This is actually the single biggest problem I've seen in test suites. I'd much prefer to see ugly un-DRY test code than overly engineered test code. The number of times I've had test suites that are passing tests by coincidence is depressingly large and is always due to this sort of behavior. Yes, we're all software devs and we like writing good code, but in tests it's much more important to be able to isolate and verify that the tests are correct than it is to be pretty.
tzahola 9y ago
Exactly. I hate it when I have to look through 5 different “fixture” classes to find out what’s being set up by a test.
kkapelon 9y ago
True, but too much of everything might be bad for you. I have seen however more projects out there that have code duplications in tests than projects that go overboard with DRY
flukus 9y ago
> but too much DRY in tests can make for hard-to-modify spaghetti This applies to all code, not just tests. Dry can turn some stupidly simple if somewhat repetitive code into a complicated mess. For unit tests though, as I general rule I don't share any setup between tests but I use the test fixture setup method for common mocks to return default answers. Even that can get too hairy at times and it's better off creating a second test fixture.

diggan 9y ago

Sure, the point is to treat test-code as "normal" production code. The things you mentioned here applies for that code as well.

arthurdenture 9y ago

Similarly, overly elaborate test code can itself be buggy. A specific instance of this anti-pattern is when the test code duplicates the same logic as the code under test, logic which turns out to be incorrect. In test code, I am a lot more tolerant of straight-line repetition in the name of simplicity, in a manner that would be worth abstracting were it in non-test-code.

rdiddly 9y ago
That's a sign that you need to write tests to test your tests. It's part of treating your test code as a first-class citizen. I always write a test suite for my test suite. Just kidding.
- squeaky-clean 9y ago
  I know this is a joke, but I do have a few "don't panic" tests that do extremely simple stuff, like just run a test and return True immediately, connect to db, connect to mock db, etc. Sometimes I do something stupid like put an extra comma somewhere without noticing, or update my db driver library without also updating my mock library. I think we've all had that moment where tests fail or it doesn't compile because you thought you copy-pasted some text into an email, but it got pasted into your editor window. So when I see that literally every test has failed, I know it was some really dumb but likely simple mistake on my part. If 180/195 tests pass.... Shit.

scaryclam 9y ago

This is actually the single biggest problem I've seen in test suites. I'd much prefer to see ugly un-DRY test code than overly engineered test code. The number of times I've had test suites that are passing tests by coincidence is depressingly large and is always due to this sort of behavior. Yes, we're all software devs and we like writing good code, but in tests it's much more important to be able to isolate and verify that the tests are correct than it is to be pretty.

tzahola 9y ago

Exactly. I hate it when I have to look through 5 different “fixture” classes to find out what’s being set up by a test.

kkapelon 9y ago

True, but too much of everything might be bad for you. I have seen however more projects out there that have code duplications in tests than projects that go overboard with DRY

flukus 9y ago

> but too much DRY in tests can make for hard-to-modify spaghetti This applies to all code, not just tests. Dry can turn some stupidly simple if somewhat repetitive code into a complicated mess. For unit tests though, as I general rule I don't share any setup between tests but I use the test fixture setup method for common mocks to return default answers. Even that can get too hairy at times and it's better off creating a second test fixture.