Cet article a pour objectif de résumer quelques recommandations relatives au TDD.
Je me suis inspiré de la présentation du coach Patrick GIRY @PatrickGIRY lors d l’agile Testing night à la SG.
Pourquoi on ajoute un test ?
- Valider une nouvelle feature
- Documentation
Travail de l’artisan / craft
- Rajouter des tests
- Écrire un code visible et maintainable
- Écrire un code avec le vocabulaire métier
- Connaître les raccourcis clavier
- Travailler en premier incréments surs( un commit à chaque étape)
- Valider souvent
- Ne pas hésiter à changer / améliorer le code
TDD
Les règles du TDD
- Ne pas écrire un code de prod avant d’avoir un TU qui échoue
- Ecrire juste le TU suffisant pour échouer
- Ecrire un code de prod pour passer juste le TU rouge
Les recommandations du coach
- Seul le refactoring est permis sans les tests
- Commencer les tests avec la branche la moins profonde
- La méthode de test doit être nommée pour décrire le comportement que le code devrait couvrir
- Mettre « should » dans le nom de la classe de test
- Mettre des « _ » entre les mots de la méthode
- Lancer les tests de manière continue pendant le coding
- Améliorer les « magic values » en mettant des constantes dans les TU. Par exemple, mettre « UNDEFINED » au lieu de « null ».
- L’objectif est de documenter le comportement.
- Faire un commit après chaque test vert
- Limiter le code redondant
- Passage en attribut pour la classe de test (TesteableService)
Le workflow
Clean tests
- lisibles
- clairs
- simples
- peu denses
- un seul concept par TU
- rapides
- indédendants
- répétables
- auto-validés
- décrivent les besoins métiers
Règles du refactoring :
- On commence par la branche la plus profonde
- Vérifier les responsabilités
- Dans le cas ou on change les responsabilités, penser à rajouter des TU
- Le code est à l’image du langage métier
Techniques de réfactoring :
- Extraction de méthode avec des dépendances extérieure dans une nouvelle méthode (niveau package)
- Surcharger la méthode dans une sous-classe crée au niveau des tests