From the paper that started this link (http://www.cwi.nl/~leon/papers/xp2001/xp2001.pdf):
	* MysteryGuest
	* ResourceOptimism
	* TestRunWar
	* GeneralFixture
	* EagerTest
	* LazyTest
	* AssertionRoulette
	* IndirectTesting
	* ForTestersOnly
	* SensitiveEquality
	* TestCodeDuplication

Other suggestions:
	* OnceAndOnlyOnce

----

Yes I am claiming that OnceAndOnlyOnce is a smell in unit test code (and therefore disagreeing with TestCodeDuplication). When a test fails I want to look at the test method and see exactly what it did. I don't want to have to hunt through lots of tiny methods, or worse, separate classes, to understand the test. I want to be able to see at a glance that there isn't a bug in the test itself. --GrahamJenkins

''Hmmmmm.....that's interesting, but potentially impractical, especially considering complex tests that need to do things like setting up database connections, populating the database, etc.   I would contend that at least modularity is still needed in those instances just to help us delimit the parts of the test that we've "tested" already from those that are unique to the particular unit test. --KyleBrown''

----

''When a test fails I want to look at the test method and see exactly what it did'' --GrahamJenkins, above

Agreed.  However, when I want to change the way something works, I don't want to have to update more than one test case.

The balance, therefore, is...
----
Production code has several clients (at least two).  

Unit test code really only has one.  

There is a large degree of flexibility which gets refactored into the production code which is simply not needed (and in some cases can be downright harmful) in test code.  Flexibity in what you ''could'' prove with a given method is not a useful trait in a test method;  the idea is that each method demonstrates one concrete task, and can determine if it was successful.

I frequently write code in test methods that I would wince at if I saw in production code.  The duplication, in this context, frequently ''gives'' me flexibility in writing the tests.  If it is really that bothersome, I've found that it usually means that the ''production'' code needs more work.

--WilliamUnderwood
----
See also: RefactoringTestCode.