Qu'est-ce qui devrait venir en premier: test ou révision de code?

Je suis assez nouveau dans la programmation des modèles de conception et des cycles de vie et je me demandais ce qui devrait arriver en premier, la révision du code ou les tests, concernant le fait que ceux-ci sont effectués par des personnes distinctes?

D'un côté, pourquoi s'embêter à revoir le code si personne ne vérifie s'il fonctionne, même? De l'autre, certaines erreurs peuvent être trouvées tôt, si vous faites la revue avant le test.

Quelle approche est recommandée et pourquoi?

Les tests unitaires des développeurs d'abord, puis la révision du code, puis les tests d'assurance qualité sont la façon dont je le fais. Parfois, la révision du code a lieu avant le test unitaire, mais généralement uniquement lorsque le réviseur de code est vraiment submergé et que c'est la seule fois où il peut le faire.

Notre norme est de faire la revue du code avant que le produit ne passe en QA. La raison en est qu'une fois que le produit a été testé et vérifié, il y a moins d'incitation à refactoriser et autrement modifier les internes du code. Il faudrait alors tout retester. Notez que nous effectuons également des tests unitaires dans la plupart des cas.

Idéalement, dans un monde agile, les deux :)

Le développement piloté par les tests est une méthode qui encourage le développement de tests unitaires avant l'écriture du code réel - de cette façon, vous pouvez capturer la spécification dans le code et écrire des tests qui réussissent les tests. Par la suite, des tests d'intégration automatisés qui garantissent que tous les différents composants s'emboîtent sont une bonne chose pour s'assurer que la fonctionnalité de votre application correspond à ce qui est attendu.

En ce qui concerne les révisions de code, la programmation par paires est un moyen utile d'avoir un autre esprit qui surplombe votre code pendant que vous l'écrivez. Cependant, ce n'est pas nécessairement une approche pratique. La façon dont cela fonctionne dans mon entreprise actuelle est que le code est examiné après avoir été testé sur la machine personnelle du développeur, mais avant d'être déployé sur un serveur de développement partagé.

La révision du code est effectuée pour «peaufiner» les choses qui fonctionnent déjà, pour s'assurer que le code a le niveau de qualité souhaité et qu'il respecte les directives de code définies par l'entreprise.

La révision du code peut également se produire dans le cadre de la future activité d'optimisation générale où vous refactorisez et améliorez l'ancien code.

Si vous pratiquez la révision de code avant de procéder à un archivage, la révision de code se situe entre deux étapes de test: vous, en tant que développeur, testez d'abord votre code, votre homologue effectue une révision de code, vous l'archivez, puis des testeurs dédiés effectueront des analyses individuelles et approfondies plus approfondies. tests d'intégration.

Testez d'abord. Test en dernier. Test, test, test.

La révision du code est agréable à avoir. Mais difficile - peut être un processus douloureux si des personnalités impliquées ou des opinions divergentes.

Les tests sont très clairs: ça marche ou ça ne marche pas. Alors testez, testez, testez! Et révisez le code si possible.

Lors de mon dernier travail, nous avions trois types différents de revues de code que nous ferions à différentes étapes du cycle de vie du produit. Le premier type que nous avons appelé Sanity Review, et cela se produirait avant qu'un développeur n'ait même fait de tests unitaires - en fait, Sanity Reviews a été fait avant même que les fonctionnalités ne soient terminées. L'idée était qu'une paire de membres de l'équipe s'asseyait et passait en revue quelques sections aléatoires de code comme c'était le cas dans le processus de développement, pour s'assurer que le développement se déroulait bien et que nous n'allions pas nous retrouver avec un géant. Entrée TDWTF une fois que la fonctionnalité était prête à être fusionnée. Cela a été fait principalement pour les personnes qui avaient besoin de conseils supplémentaires (développeurs juniors, nouveaux employés et personnes affectées à travailler sur quelque chose qu'ils connaissaient moins que les autres membres de l'équipe), et était généralement limité à une brève réunion qui ne traitait que des problèmes graves.

Ensuite, nous avons eu des revues d'unité. Celles-ci étaient généralement effectuées avec trois développeurs et le seraient lorsqu'une unité / fonctionnalité aurait été testée et serait prête à être fusionnée dans l'arborescence principale. Ce fut la revue la plus charnue et entrerait dans pas mal de détails. Nous avions trois développeurs pour cela, car nous avions l'auteur original du code, le mainteneur de l'arborescence qui devait se déconnecter du code avant qu'il puisse être fusionné, et un troisième développeur qui avait été sélectionné pour être la sauvegarde du développeur d'origine. (l'idée étant qu'une fois une section de code terminée, il devrait y avoir un transfert complet des connaissances à un autre membre de l'équipe, donc il y avait toujours au moins 2 personnes dans l'équipe qui étaient parfaitement à l'aise avec n'importe quelle partie de la base de code).

Enfin, nous avons eu des revues de projets. Cela englobait toute l'équipe et prendrait environ une semaine, et a été effectué après le contrôle qualité et le lancement du produit, et l'objectif était de faire en sorte que tout le monde s'asseye et passe en revue toutes les modifications apportées à l'ensemble de la base de code au cours du dernier cycle de publication, où tout le monde pouvait parler des changements architecturaux, des pièges et décider de ce qui devait être refactorisé et corrigé avant de commencer le développement de la prochaine version du projet.

Tout d'abord, écrivez des tests automatisés pour le code à développer. Passez en revue les tests pour vous assurer que toutes les exigences connues sont testées. Écrivez le code. Passez en revue aussi souvent que vous le souhaitez.

Si des tests manuels sont nécessaires, il est essentiel de revoir le code avant d'effectuer des tests manuels. Sinon, les améliorations de conception suggérées dans la révision du code seront rejetées car les tests manuels devront être réexécutés.

Quel est le premier, l'œuf ou le poulet?
Ça dépend.

Si vous êtes nouveau et que vous n'êtes pas sûr de ce que vous faites, demandez par tous les moyens à un pair de vous aider. Il s'agit d'une révision de code informelle mais très sérieuse et précieuse.

En général, même si je suggère que vous fassiez d'abord votre propre sale boulot, assurez-vous d'avoir aplani le code, de bien le commenter aux bons endroits (c'est-à-dire les bits difficiles, pas les plus évidents), cela fonctionne au moins fondamentalement (vous avez testés au minimum et dans certains cas limites ou exceptions). Ensuite, vous l'apportez à votre homologue.

Faire réviser votre code trop tôt pourrait se traduire par une perte de temps terrible pour vos pairs. Le faire réviser trop tard pourrait se traduire par une perte de temps terrible. Vous devez trouver le bon équilibre pour une efficacité maximale. Donc, certains tests passent d'abord, puis la révision, puis d'autres tests. Potentiellement, vous pouvez avoir plusieurs révisions de code, selon la complexité et les itérations, avec des objectifs et des objectifs différents.

Moins vous êtes sûr, plus il y a de commentaires (lorsque vous êtes dans votre première phase d'apprentissage, c'est normal). Plus vous êtes sûr, plus vous avez d'avis aussi (il n'est jamais bon d'être trop sûr de vous, cela signifie que vous n'êtes généralement pas aussi bon joueur d'équipe et que vous pourriez causer des ennuis aux autres, vous devez vous assurer que votre code peut être compris et utilisé par d'autres). C'est lorsque vous êtes au milieu que les avis peuvent être espacés.

Seulement mes deux cents.

Capers-Jones, qui a étudié et mesuré plus que quiconque l'efficacité et la qualité des processus de développement logiciel qui en résulte, recommande la séquence suivante d'activités d'élimination des défauts:

• Inspections de conception
• Inspections du code
• Tests unitaires
• Nouveaux tests de fonction
• Tests de régression
• Des tests de performance
• Tests système
• Tests bêta externes

L'une des raisons pour lesquelles l'inspection du code a été effectuée avant les tests est que l'examen peut prendre en compte non seulement le code lui-même, mais aussi la testabilité du code.