Les trois règles du Test Driven Development

Au cours des ans, j’ai été amené à décrire le Test Driven Development en utilisant trois règles simples :
1. Vous ne devez écrire du code de production que pour faire réussir un test qui échoue.
2. Vous ne devez écrire que le test unitaire que nécessaire pour échouer; les problèmes de compilation sont aussi considérés des échecs.
3. Vous ne devez écrire que code de production nécessaire pour faire réussir un test unitaire qui échoue.

Vous devez commencer par écrire un test unitaire pour la fonctionnalité que vous voulez développer. Mais la règle numéro deux vous empêche d’écrire un long test. Dès que le code du test échoue à la compilation ou à l’exécution, vous devez écrire le code de production. La règle numéro trois ne vous autorise à écrire seulement le code nécessaire pour que le test unitaire puisse compiler ou s’exécuter, rien de plus.

Lorsque vous réfléchissez, vous réalisez que vous ne pouvez pas écrire beaucoup de code avant de compiler et d’exécuter quelque chose. C’est exactement l’effet désiré. Que nous écrivions des tests unitaires ou du code de production ou si nous faisons du refactoring, nous devons exécuter l’application à tout moment. L’intervalle entre l’exécution des tests doit se compter en secondes ou minutes. Même 10 minutes est un intervalle trop long.

Robert  Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Au-delà de ces règles spécifiques et des approches agiles, en tant que développeur j’ai toujours aimé vérifier fréquemment mon code, ceci rend beaucoup plus facile la détection des mes erreurs ;o)