Le développement piloté par les tests est de plus en plus répandu et il existe de bonnes preuves empiriques qu’il s’agit d’une pratique bénéfique. TDD réduit le nombre de bugs en production et améliore la qualité du code. En d’autres termes, cela rend le code plus facile à maintenir et à comprendre. En outre, il fournit des tests automatisés pour les tests de régression.
Le TDD est-il vraiment utile ?
Lorsque vous écrivez des tests, vous écrivez plus de code, mais des études ont montré objectivement qu’une bonne couverture de test avec TDD peut réduire la densité de bogues de 40 à 80 %.
Quand dois-je utiliser TDD ?
TDD se prête très bien lorsque vous avez une fonction logique pure que vous devez écrire. Lorsque le travail que vous devez effectuer a un ensemble clairement défini d’entrées et de sorties attendues, c’est un excellent signal que vous devez utiliser TDD pour créer vos tests et votre code.
Le TDD est-il une bonne approche ?
Les développeurs ont moins de débogage à faire Moins de bogues et d’erreurs sont le principal avantage de l’approche TDD. Lorsque le code contient moins de bogues, vous passerez moins de temps à les corriger que d’autres méthodologies de programmation. TDD produit une couverture de test globale plus élevée et, par conséquent, une meilleure qualité du produit final.
Pourquoi le TDD est-il une mauvaise idée ?
C’est généralement une mauvaise idée – la plupart des praticiens TDD expérimentés peuvent dire si les tests unitaires ont été écrits avant ou après le code. Un développeur qui écrit des tests unitaires après avoir écrit son code passe à côté de l’essentiel – TDD est une méthodologie de conception – les tests unitaires ne sont qu’un sous-produit du processus.