Unit Test application de production stable

Question

Il semble une vérité absolue dans la communauté de développement que Unit Test est un must, et vous devriez l'ajouter tout ce qu'il coûte (je sais que ce n'est pas 100% comme ça). Laissez-moi jouer l'avocat du diable ici.

La direction veut introduire des tests unitaires dans l'espoir de minimiser les erreurs de développement de régression dans chaque cycle de développement. < - Voici où je pense que nous pouvons utiliser le mauvais remède. Il s'agit d'une application web MVC, avec un bon niveau de découplage mais avec un vaste code .js difficilement testable, des procédures stockées, etc. Souvent, les erreurs de régression se produisent en raison d'erreurs d'implémentation ou de fusion.

Donc, je ne demande pas comment ajouter Unit Testing à un code existant, qui est abondamment répondu dans le bas du lien. Mon plan initial était de construire des tests d'intégration avec de nombreux scénarios, qui couvriraient l'application «entière». Il semble plus précieux que 5000+ tests unitaires. Ensuite, nous pourrions essayer d'ajouter des tests unitaires au fur et à mesure et nous pourrions voir le bénéfice se prouver, si c'est vraiment le cas. En outre, certains des avantages des tests unitaires me semblent vagues, ils vous permettent de remplacer les frameworks sans casser l'application, et vous permettent de refactoriser le code sans casser l'application.

Maintenant, je demande:
Réduit-elle efficacement les erreurs de régression?

Pouvez-vous écrire des tests unitaires sans réécrire l'application de manière substantielle?

Pouvez-vous promettre que le code de refactoring ne génèrera pas de nouveaux bogues coûteux? (Je sais que ce n'est pas une question valide) Comment expliquez-vous aux entreprises que vous avez cassé le refactoring de l'application?

Qu'en est-il de l'historique du code? Parfois, il est très important pour l'audit de savoir pourquoi du code a été introduit et que le refactoring perd cette valeur. Si vous êtes chanceux, vous ne le trouverez que très longtemps dans le contrôle de la source.

Je sais que vous lisez ceci et je suis un de ces gens fermés qui ne changera pas d'opinion, je promets que je ne suis pas! À la fin de la journée, nous avons besoin de beaucoup plus de stabilité que d'éviter une poignée de défauts ré-ouverts. Et j'aimerais trouver le chemin le plus efficace pour commencer.

Dernier point mais non le moindre, j'ai lu cet autres discussions qui est génial.

Can unit testing be successfully added into an existing production project? If so, how and is it worth it?

S'il vous plaît partager vos pensées.

Merci

Answer 1

Je pense que des tests de niveau de niveau d'intégration ou d'acceptation qui couvrent de larges pans de l'application peut être une bonne façon de commencer. Il sera probablement plus facile d'écrire que les tests unitaires.

à vos questions:

Est-ce que [les tests unitaires] minimiser efficacement les erreurs de régression?

Oui, si vous ajoutez les types de tests appropriés.Chaque fois que je rencontre un bug dans le code, j'écris un test unitaire qui exploite ce bug pour provoquer l'échec du test. Lorsque le bug est corrigé, le test passe. Une fois que ce test ou groupe de tests est dans votre suite de tests, vous ne devez jamais réintroduire le bogue car cela entraînerait l'échec des tests. Cependant, ceci nécessite 1) que vous écrivez les tests qui exploitent le bogue, 2) que vous exécutiez les tests régulièrement pour détecter les régressions. et 3) seul le logiciel qui réussit tous les tests est libéré. Pouvez-vous écrire des tests unitaires sans réécrire l'application de manière substantielle?

C'est possible, mais peu probable. Une application qui est déjà en production sans tests n'a probablement pas été conçue pour être testée. Il est donc probable que le code devra être refactorisé, peut-être de façon significative afin de le tester correctement.

Pouvez-vous promettre refactoring code ne générera pas de nouveaux bugs coûteux? (Je sais que ce n'est pas une question valide)

Non, vous ne pouvez pas le promettre. Surtout si vous avez besoin de refactoriser le code sensiblement avant d'avoir une bonne couverture de test pour agir comme un filet de sécurité. Cependant, cela devrait être rare, surtout si vous avez déjà écrit vos tests d'intégration. Comment expliquer aux entreprises que vous avez rompu le refactoring de l'application? Avant de procéder à un refactoring logiciel majeur, j'espère que vous avez travaillé avec vos parties prenantes sur ce que serait le plan de refactoring. Ils auraient dû être bien informés des risques et des temps d'arrêt potentiels à court terme pour améliorer la fiabilité et accélérer le développement à long terme. Avant que le projet soit approuvé!

Qu'en est-il de l'historique du code? Parfois, il est très important pour l'audit de savoir pourquoi du code a été introduit et que le refactoring perd cette valeur. Si vous êtes chanceux, vous ne le trouverez que très longtemps dans le contrôle de la source. Eh bien, comme vous l'avez dit, vous avez le contrôle de la source pour montrer l'historique en dernier recours. Mais si le problème est d'une telle importance, vous devriez probablement écrire des tests comme s'il s'agissait d'un bug comme je l'ai déjà décrit. De cette façon, vous obtiendrez des tests échoués si votre refactoring réintroduit ce problème.

Refactoriser une application existante pour écrire des tests unitaires (puis écrire ces tests unitaires) est une entreprise majeure et ne devrait pas être faite à la légère.

J'ai une fois complètement refaçonné/remodelé une ancienne application de 400k + LOC critique dans ma propre entreprise. Il a fallu de nombreuses années de presque 100% d'efforts. Au moment où j'étais «fini» et que les 20% du code les plus critiques étaient couverts et l'architecture repensée à un niveau compréhensible et maintenable, le paysage de l'industrie avait changé et l'application n'était plus importante. Heureusement, au cours du projet, j'ai réalisé environ 100 versions, ce qui a permis aux utilisateurs de profiter de la stabilité améliorée et des nouvelles fonctionnalités avant que le projet ne soit détruit. Je pense que mon point est, assurez-vous que cela en vaut la peine avant de commencer ce chemin.