Nous écrivons des tests pour vérifier l'exactitude du comportement d'un programme.
Vérifier l'exactitude du comportement d'un programme en inspectant le contenu des instructions de sortie à l'aide de votre yeux est un processus manuel , ou plus spécifiquement visuel .
Tu pourrais dire que
l'inspection visuelle fonctionne , je vérifie que le code fait ce qu'il est censé faire, pour ces scénarios et une fois que je peux voir que c'est correct, nous sommes prêts à partir.
Maintenant, tout d'abord, c'est formidable de savoir si le code fonctionne correctement ou non. C'est une bonne chose. Vous êtes en avance sur la courbe! Malheureusement, cette approche pose des problèmes.
Le premier problème avec l'inspection visuelle est que vous êtes un grave accident de soudage loin de ne plus jamais pouvoir vérifier l'exactitude de votre code.
Le deuxième problème est que la paire d'yeux utilisée est étroitement liée au cerveau du propriétaire des yeux. Si l'auteur du code possède également les yeux utilisés dans le processus d'inspection visuelle, le processus de vérification de l'exactitude dépend de la connaissance du programme internalisée dans le cerveau de l'inspecteur visuel.
Il est difficile pour une nouvelle paire d'yeux d'entrer et de vérifier l'exactitude du code simplement parce qu'elle n'est pas associée au cerveau du codeur d'origine. Le propriétaire de la deuxième paire d'yeux devra s'entretenir avec l'auteur original du code afin de bien comprendre le code en question. La conversation comme moyen de partage des connaissances est notoirement peu fiable. Un point qui est discutable si le codeur d'origine n'est pas disponible pour la nouvelle paire d'yeux. Dans ce cas, la nouvelle paire d'yeux doit lire le code d'origine.
La lecture du code d'autres personnes qui n'est pas couvert par les tests unitaires est plus difficile que la lecture du code auquel sont associés des tests unitaires. Au mieux, lire le code des autres est un travail délicat, au pire c'est la tâche la plus compliquée du génie logiciel. Il y a une raison pour laquelle les employeurs, lorsqu'ils publient des offres d'emploi, soulignent qu'un projet est un projet nouveau (ou tout nouveau). Écrire du code à partir de zéro est plus facile que de modifier le code existant et rend ainsi l'emploi annoncé plus attrayant pour les employés potentiels.
Avec les tests unitaires, nous divisons le code en ses composants. Pour chaque composant, nous avons ensuite établi notre stand en indiquant comment le programme devrait se comporter . Chaque test unitaire raconte comment cette partie du programme doit agir dans un scénario spécifique. Chaque test unitaire est comme une clause dans un contrat qui décrit ce qui doit se passer du point de vue du code client.
Cela signifie alors qu'une nouvelle paire d'yeux a deux brins de documentation en direct et précise sur le code en question.
Tout d'abord, ils ont le code lui-même, l'implémentation, comment le code a été fait ; deuxièmement, ils ont toutes les connaissances que le codeur d'origine a décrites dans un ensemble d'instructions formelles qui racontent l'histoire de la façon dont ce code est censé se comporter.
Les tests unitaires capturent et décrivent formellement les connaissances que l'auteur original possédait lors de la mise en œuvre de la classe. Ils fournissent une description du comportement de cette classe lorsqu'elle est utilisée par un client.
Vous avez raison de remettre en question l'utilité de faire cela car il est possible d'écrire des tests unitaires qui sont inutiles, ne couvrent pas tout le code en question, deviennent périmés ou obsolètes, etc. Comment pouvons-nous nous assurer que les tests unitaires non seulement imitent mais améliorent le processus d'un auteur compétent et consciencieux qui inspecte visuellement les instructions de sortie de son code au moment de l'exécution? Écrivez d'abord le test unitaire, puis écrivez le code pour que ce test réussisse. Lorsque vous avez terminé, laissez les ordinateurs exécuter les tests, ils sont rapides, ils sont parfaits pour effectuer des tâches répétitives, ils sont parfaitement adaptés au travail.
Assurez la qualité des tests en les examinant à chaque fois que vous touchez le code qu'ils testent et exécutez les tests pour chaque build. Si un test échoue, corrigez-le immédiatement.
Nous automatisons le processus d'exécution des tests afin qu'ils soient exécutés à chaque fois que nous faisons une compilation du projet. Nous automatisons également la génération de rapports de couverture de code qui détaille le pourcentage de code couvert et exercé par les tests. Nous visons des pourcentages élevés. Certaines entreprises empêcheront l'archivage des modifications de code dans le contrôle du code source si elles n'ont pas suffisamment de tests unitaires écrits pour décrire tout changement de comportement du code. En règle générale, une deuxième paire d'yeux examinera les modifications du code en collaboration avec l'auteur des modifications. Le réviseur passera en revue les changements pour s'assurer que les changements sont compréhensibles et suffisamment couverts par des tests. Le processus d'examen est donc manuel, mais lorsque les tests (tests unitaires et d'intégration et éventuellement tests d'acceptation des utilisateurs) réussissent ce processus de révision manuelle, ils font partie du processus de construction automatique. Ceux-ci sont exécutés chaque fois qu'une modification est enregistrée.Intégration continue Le serveur exécute cette tâche dans le cadre du processus de construction.
Les tests qui sont automatiquement exécutés, maintiennent l'intégrité du comportement du code et aident à empêcher les futures modifications de la base de code de casser le code .
Enfin, fournir des tests vous permet de re-factoriser le code de manière agressive, car vous pouvez apporter des améliorations importantes au code en sachant que vos modifications ne cassent pas les tests existants.
Il y a une mise en garde concernant le développement piloté par les tests , à savoir que vous devez écrire du code en vue de le rendre testable. Cela implique le codage des interfaces et l'utilisation de techniques telles que l'injection de dépendances pour instancier des objets collaboratifs. Découvrez le travail de Kent Beck qui décrit très bien le TDD. Rechercher le codage des interfaces et étudiermodèles de conception