Un ottimo articolo di Roy Osherove su MSDN magazine di gennaio, sui principali errori che si commettono quando si inizia scrivere unit tests per fare Test Driven Development.

"In this article, I'll try to bring you some of the most important practices I've learned over the years while developing and consulting, and while training developers. These tips should help you write effective, maintainable, and robust unit tests. And I hope this advice helps you to avoid huge amounts of wasted time and effort."

Una delle parti che piu' mi sono piaciute:

"How do you know if you have good coverage for your new code? Try removing a line or a constraint check. If all tests still pass, you don't have enough code coverage and you probably need to add another unit test. The best way to make sure you are adding the correct test is to not uncomment that line or check until you produce a test that fails until you do uncomment it. This may be hard, but if you can't think of a way to make this code fail, you probably don't have a good reason for writing that line of code in the first place."

Praticamente se c'e' una linea di codice non coperta da test, e non so come scrivere un test che la copra, probabilmente quel codice non dovrebbe essere li. Il che mi fa capire che ho sbagliato il design e ho scritto codice che non mi servira'. 
Questo, secondo me, sintetizza in poche righe una buona parte della filosofia TDD.

powered by IMHO 1.3