I’ve been following an interesting thread on the test driven development list around identifying anti-patterns in test suites. James Carr has collated and written them up and I can recommend it as a great read. Many I agree with, some I don’t but overall this is a great list and should get any developer thinking again about the tests they’re writing. I need a name for an anti-pattern I often fall foul of. It occurs when I’m refactoring – often I extract classes without tests because they’re covered by the tests on the original class that the logic was extracted from. To repeat the tests for the new class smacks of duplication but the danger is that the original class gets removed leaving the new class without any tests at all. Anyone else have this anti-pattern and, better still, a good name for it?
-
Ian Davis: British; married with kids; technical architect; CTO of Talis; co-author of RSS 1.0; creator of FOAF icons; Semantic Web hacker.
My URI:
http://iandavis.com/id/me
Email Me:
nospam@iandavis.com
Twitter:
http://twitter.com/iand
I too find myself doing this, especially if the original tests would require a lot of re-work to pull out that responsibility. What’s happening is that the new class becomes “orphaned” from its original parent tests. <overly dramatic > I see tests giving birth to the design of the code in TDD. </overly dramatic >I nominate the Test Orphan anti-pattern.Perhaps the Dependency Injection pattern helps here. By insisting on having an instance of the new class be given to the dependant class the tests may become clearer even if it doesn’t directly allow you to re-factor the tests.