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é.
- Essayez de créer des tests d'intégration au niveau du système pour entourer le code. En raison de la complexité combinatoire des tests à ce niveau, ces tests ne formeront qu'un test de «fumée» pour détecter les erreurs majeures.
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.
- Ecrivez des tests pour couvrir autant que possible la fonctionnalité du code que vous allez modifier. Enregistrez-vous régulièrement et passez en revue tous les changements.
- Rédiger des tests pour la nouvelle fonctionnalité / modification de fonctionnalité.
- Implémentez la fonctionnalité (c'est votre cycle TDD normal)
- Assurez-vous de refactoriser les zones couvertes par les tests (refactor rouge-vert).
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.
pingouin flamant
la source
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 =)
la source
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é.
la source