Le test unitaire est-il un accord à 100% ou pas du tout?
Je parcourais mes anciens projets et j'ai commencé à ajouter des fonctionnalités, cette fois avec des tests unitaires. Cependant, est-ce finalement inutile si je vais réutiliser d'anciens composants qui n'ont pas de tests unitaires?
Dois-je écrire des tests unitaires pour toutes les classes précédentes et ne pas me déranger du tout, ou est-ce OK de n'écrire que des tests unitaires pour les nouvelles choses que j'ajoute?
Réponses:
Tous les tests unitaires sont meilleurs qu’aucun. Ce n'est donc pas un accord tout ou rien.
Dans votre cas, le développement piloté par les tests n'étant pas la norme, vous vous demanderez à quoi servent les tests.
Vous voulez vous assurer que tout code futur que vous écrivez ne casse aucune fonctionnalité (actuelle) - et c'est là que vos sous-cas sont utiles. Si les tests bien écrits réussissent, vous n'avez probablement rien endommagé. Le prochain développeur qui viendra vous remerciera pour les tests et la documentation.
Ce que vous pouvez commencer, c'est si vous avez une architecture en couches bien divisée, choisissez les niveaux d'accès aux données et travaillez vers le haut (vers le niveau de l'interface utilisateur) avec les tests. Si le projet a un modèle de domaine, c'est le candidat le plus probable pour TDD car il est susceptible d'avoir la plupart de la logique. Si le niveau service (ou logique métier) effectue simplement un appel au niveau domaine / accès aux données, inutile de faire le niveau service de manière TDD. Ce sont des tests moelleux et peu utiles.
Ajouté à un outil de couverture de code comme Emma - et vous pouvez surveiller régulièrement l'amélioration de la couverture globale des tests.
J'ai travaillé sur une très grande base de code qui au départ n'avait pas de tests unitaires. En suivant quelques pratiques, nous avons maintenant (après plusieurs années) la majeure partie de la base de code couverte par les tests.
Tout nouveau code doit avoir des tests unitaires.
Tous les codes modifiés doivent avoir des tests unitaires ajoutés.
La façon dont nous avons ajouté des tests en toute sécurité à l'ancien code sans le casser consiste principalement à utiliser l'approche de base suivante:
Choisissez une petite section de code dont vous avez besoin pour modifier la fonctionnalité.
Présentez les interfaces dont vous avez besoin pour pouvoir tester le code que vous modifiez. Utilisez des techniques de refactoring consistant en des séquences de très petits changements dont vous avez une grande confiance sont correctes. Essayez d'utiliser le support d'outils lorsque cela est possible. Pour ce faire, vous pouvez, par exemple, déplacer / extraire la méthode que vous modifiez sur son propre objet. Vérifiez régulièrement vos modifications afin de pouvoir revenir en arrière. Examinez régulièrement par les pairs comment vous avez apporté les modifications en parcourant l'historique du contrôle des révisions.
Essayez de faire le minimum de modifications nécessaires afin de briser les dépendances qui vous empêchent d'ajouter des tests.
Nous avons constaté que plus nous faisions cela, plus c'était facile. Comme à chaque fois que vous revenez à la base de code, c'est un peu mieux.
Nous avons constaté une baisse massive du nombre de bogues transmis à nos testeurs d'assurance qualité. Les régressions fonctionnelles étant maintenant presque inconnues, je pense que cela valait la peine pour nous.
(pour le manque de capacité de commenter) Je pense qu'il vaut mieux que de ne pas tester du tout. Tous les extraits ne doivent pas être testés, mais uniquement ce qui sera éventuellement utilisé par le programmeur. Tester les fonctions utilitaires que vous utilisez en interne est bon, mais pas obligatoire si vous accédez à tout via une API propre par la suite.
Si les anciens éléments fonctionnent bien depuis des années, la création des tests unitaires n'est désormais pas obligatoire, sauf si vous modifiez quelque chose dans les anciens éléments. Quoi qu'il en soit, l'écriture de tests unitaires pour les nouvelles pièces n'est pas du tout inutile. Les nouvelles parties sont les plus susceptibles de contenir des bogues, et elles sont également les plus susceptibles d'être modifiées ou refactorisées.
Vous pouvez commencer à couvrir votre code actuel et, si vous avez du temps à consacrer, commencer à couvrir les fonctionnalités de base de l'ancien code. Vous pouvez également demander à votre PM un temps supplémentaire pour cela =)
Le test unitaire est-il un accord à 100% ou pas du tout?
Absolument pas! Commencez à tester le nouveau code que vous ajoutez. Vous constaterez d'énormes avantages à le faire, même si certains des composants plus anciens n'ont pas de tests. Comme vous devez gérer l'un de ces composants ou y trouver un bogue, écrivez un test. Au fil du temps, vous obtiendrez plus de l'ancien code testé.