Les tests unitaires lors de la révision du code sont un mauvais substitut aux tests unitaires pendant le développement.
Ce que vous proposez a beaucoup de sens, intuitivement. À quoi sert la revue? Pour vérifier que le code est bon. À quoi servent les tests? Pour vérifier que le code est bon. Alors pourquoi ne pas combiner les deux?
Voici pourquoi.
Mettre le code sous test est un travail difficile. Écrire du code qui fonctionne uniquement à la seule chose qu'il est censé faire est une chose; écrire du code qui peut être testé de manière efficace et efficiente en est une autre. Le simple fait que le code s'exécute maintenant selon deux scénarios - "travail réel" et "test" - exige une flexibilité beaucoup plus grande, exige que ce code soit capable de se suffire à lui-même de manière significative.
Écrire votre code pour qu'il soit testable est un travail et des compétences supplémentaires. Refactoriser le code de quelqu'un d' autre pour la testabilité, alors qu'il n'a pas été écrit avec la testabilité en tête pour commencer, peut être une tâche majeure.
Vous dupliquez l'effort entre le développeur et le réviseur. Vraisemblablement, votre développeur ne remet pas son code pour examen sans au moins un certain niveau de confiance que cela fonctionne. Il a déjà besoin de tester le code. Maintenant, il existe différents niveaux et étendues de test. Le contrôle qualité teste le code après le développeur et le réviseur. Mais quelle que soit la portée que vous pensez appropriée pour le développeur et le réviseur, cela n'a aucun sens pour le développeur de comprendre comment tester le code à ce niveau une fois , mais de rendre ses tests jetables et difficiles à reproduire, puis d'amener le réviseur à développer à nouveau le test, cette fois automatisés et reproductibles. Vous avez juste tous les deux investi du temps à écrire les mêmes tests - une fois mal, une fois bien.
Vous transformez l'examen en une étape beaucoup plus longue et plus laborieuse. Si les tests constituent une partie importante du processus d'examen, que se passe-t-il lorsque certains tests échouent ? L'examinateur est-il responsable de l'exécution de tous les tests, il doit donc également déboguer le code? Ou est-ce que ça va être ping-pong dans les deux sens, l'un écrit des tests, l'autre les fait passer?
Parfois, vous pouvez écrire tout un tas de tests qui sont tous orthogonaux les uns aux autres, vous n'avez donc pas besoin de faire du ping-pong. Le réviseur écrit une douzaine de tests, la moitié d'entre eux échouent, le développeur corrige les bugs et tous les tests restent valides, et passent maintenant. Mais ... la plupart du temps, vous avez des bogues bloquants, ou des bogues qui nécessitent une refonte et des changements d'API, ou autre chose. Si vous jetez la responsabilité de passer des tests dans les deux sens entre le réviseur et le développeur, alors vous n'êtes pas réellement au stade de la révision. Vous êtes toujours en développement.
La nécessité de passer des tests n'incite pas à un examen plus approfondi. Cela signifie essentiellement que plus vous allez en profondeur, plus vous devez écrire de tests, et ce seront probablement des tests difficiles qui doivent être approfondis dans le système.
Comparez avec le développeur qui écrit les tests, où sa motivation est: si je n'écris pas de tests importants, le réviseur le soulignera dans la revue.
Même le réviseur aura une bien meilleure compréhension du système s'il doit passer en revue des tests approfondis du code , puis s'il doit décider par lui-même quand elle peut arrêter d'écrire un test de recherche approfondie et juste OK la révision du code.
Si le développeur n'écrit pas de tests unitaires, le réviseur ne le fera pas non plus. Il existe de nombreux obstacles à l'adoption du test comme pratique courante. Peut-être que vous êtes trop sous pression et que votre base de code est difficile à tester. Peut-être que vous n'êtes pas très expérimenté dans les tests et que vous ne pouvez pas vous permettre la courbe d'apprentissage. Vous avez peut-être un meurtrier à la hache qui envoie des notes menaçantes aux personnes qui passent des tests. Je ne sais pas!
Mais quelle qu'en soit la cause, il est sûr de parier que cela s'applique aussi bien au réviseur qu'au développeur. Si l'équipe est stressée, le réviseur n'a pas plus de temps que le développeur (si elle le fait, redistribuez le travail afin que les gens ne soient pas aussi stressés ). Si personne ne sait bien écrire les tests unitaires, le réviseur ne le fait probablement pas non plus (si elle le fait, elle devrait s'asseoir et enseigner à ses coéquipiers ).
Cette suggestion ressemble à essayer de passer la balle d'un collègue à un autre. Et je ne vois tout simplement aucun moyen pour que cela fonctionne bien, d' abord et avant tout parce qu'il est vraiment difficile (et malsain) de créer une situation où une personne est la seule à pouvoir faire des tests et une autre personne ne peut pas le faire. aucun test du tout.
Ce qui fonctionne, c'est d' avoir également les tests de couverture. Si le développeur a déjà écrit dix tests, il est beaucoup plus probable que le réviseur puisse suggérer dix autres tests que si le développeur n'en avait pas écrit.
Et, si le test des cas d'angle est une tâche majeure, il pourrait être judicieux de le distribuer plus largement dans l'équipe. ** Une fois que le code est testable en premier lieu, écrire plus de tests devient beaucoup plus facile. **
La révision est le moment idéal pour repérer les cas d'angle. Et, si la critique peut intervenir et écrire un test pour les cas d'angle qu'elle trouve, alors bon - tant mieux! Mais de manière générale, en supposant que le réviseur puisse écrire des tests où le développeur ne semble pas être une très mauvaise idée.