J'ai quelques applications de rails de taille moyenne que je travaille régulièrement, et une seule d'entre elles a des tests unitaires du tout. Mais j'ai vu la lumière et je veux changer tout ça, sauf ... Je n'ai pas le temps d'entrer et de commencer à écrire des tests de cours par classe ou quelque chose comme ça.
Comment commencez-vous à écrire des tests unitaires sur une base de code existante - et de fonctionnement? Par exemple, puisque toute approche devrait être incrémentielle, comment commanderiez-vous votre rédaction de test unitaire? Commencez par des tests superficiels, puis passez à plus de couverture ou couvrez quelques classes ... etc.
7 Réponses :
L'augmentation de la couverture du code est un excellent moyen d'obtenir une nouvelle recrue familière avec une base de code.
Autre que je pense que vous avez juste besoin de trouver du temps, il n'y a pas de solution magique!
Voici comment je commence habituellement à ajouter des tests d'unité à un projet qui n'a pas commencé de cette façon: attendez que quelqu'un dépose un bogue, écrivez un test d'unité qui reproduit le bogue. Puis corrigez le test de l'unité. Cela commence non seulement aux tests d'unité de construction, mais maintenant personne ne peut vous accuser d'une régression pour le bogue donné.
Tests unitaires! = Tests de régression.
Ma réponse n'est pas spécifique à Ruby sur rails. La prochaine fois que vous devez toucher le codeBase, pour corriger un bogue ou ajouter une nouvelle fonctionnalité, écrire des tests pour les parties du code que vous touchez. Si vous pouvez épargner quelques minutes, ajoutez des tests connexes. Si vous constatez que vous devez refroidir, allez-y et écrivez les tests pour soutenir cela. Avec le temps, vous construirez la couverture de test et vous trouverez que vous avez toujours des tests pour les zones dont vous avez besoin (car ce sont les tests que vous écrivez).
Mots-clés ici - "Si vous pouvez épargner quelques minutes". Comme je l'ai remarqué, les projets sans tests d'unité ne sont pas des tests unitaires du tout. Ces minutes pourraient devenir rapidement en heures et les jours.
@Arnis L., comme je l'ai mentionné dans mes commentaires à une autre réponse, les langues dactylographiées dynamiquement sont plus conviviales que d'autres, vous pouvez donc toujours faire en forme. Cela dit, je vais vérifier dans quelques mois et voir si je pense toujours que :)
@Arnis L. La raison pour laquelle votre autre poste a été évité est que nous avons supposé que vous plaisantais. C'est en fait une réponse intéressante, si vous voulez le remettre, s'il vous plaît.
@yar I Undroted juste parce que vous avez dit que c'était intéressant. Mais c'est assez inutile - vous n'avez pas demandé si des tests unitaires sont nécessaires et j'ai un peu oublié que nous parlons de Ruby. Les langues dynamiques vous oblige presque à écrire des tests, ce qui les omettez-leur n'est pas une option car je pensais que cela pourrait être (qui pourrait réellement aider dans certains cas).
@Arnis L., il y a une réponse là quelque part (dans la dernière version). Vous pouvez simplement vouloir déplacer des trucs dans votre réponse à l'aide du bouton "Modifier".
L'un des problèmes que j'ai confrontés lorsque j'ai commencé à écrire des tests d'unité réels (avec des moqueurs et etc.) est que je avait pour revenir en arrière et changer le code pour soutenir l'injection des objets masculins surtout à travers l'extraction d'interfaces. Je crois que ce sera assez difficile pour vous de le faire sur un système existant sans une sorte de refactoring.
@Yar - C #, mais je soupçonne la même chose pour être vrai d'autres langues.
Pas sûr de cela: je crois que plus la langue est dactylographiée de manière dynamique, plus il est facile d'ajouter plus de tests d'unités. Ironiquement, plus ils sont nécessaires, car vous n'obtenez aucune sécurité de la compilation. Je ne suis pas vraiment convaincu des tests de Java, mais pour Groovy, je suis sûr que je ne peux pas vivre avec eux (même si j'ai jusqu'à présent).
à long terme, les tests unitaires devraient faire de la fonctionnalité (fonctionner!) aux utilisateurs plus rapidement.
Si cela n'aboutit pas cela, cela ne vaut pas la peine.
Essayer d'éviter le débat sur les tests unitaires dans cette question. Mais pendant que nous sommes ici, je pense qu'avec une langue dynamique comme Ruby, vous devez tester un appareil.
@Arnis L., non: Je pense que votre réponse vaut la peine de quelque chose. Mais peut-être pas pour cette question :)
@yar C'est juste la même idée que l'on devrait connaître tout ou au moins la plupart des options (même celles qui sonnent généralement complètement mal) avant de continuer au lieu de choisir en premier ce genre de convivialité.
avec du temps limité? Face à des délais?
Oubliez les tests de l'unité!
cow-boy coding 4 la victoire!
Caractéristiques du piratage ensemble jusqu'à ce qu'il ne soit pas trop tard et que le client n'a pas poursuivi votre entreprise.
P.s. Pour votre propre sécurité - Ne pas oubliez d'informer de la situation de votre PM.
étrange que les votes avalanches n'ont pas encore commencé. Peut-être que ce n'est pas si grave et dire de ne pas écrire des tests d'unité n'est pas un tel tabou du tout.
Je suis dans une situation similaire (en supposant que votre temps est vraiment limité). Ce que je fais - je ne pense pas aux tests de l'unité la plupart du temps. Mais pour certains cas - il est plus facile de faire TDD que de continuer le piratage (EMM ... Ducking ": D) tout ensemble (généralement lorsque l'unité testable a une complexité élevée ou est difficile à tester manuellement), puis je viens de changer d'avis et code normalement. À court terme - je serai en mesure de comprendre ce que j'ai écrit il y a un mois et cela ne fera pas beaucoup de peine. Des problèmes se poseront lorsque le projet glissera dans la phase de maintenance. Mais il est encore beaucoup mieux que de dire au client que vous avez travaillé sur des tests et n'a rien de nouveau .
Lorsque vous devez démarrer le test unitaire dans le projet existant - commencez par votre propre fonctionnalité. Créer une infrastructure de test nécessaire (si le temps le permet - une intégration continue aussi) et n'oubliez pas d'enseigner des tests unitaires à vos collègues.
pire chose que vous (ou pm) peut faire - pour forcer à écrire des tests de l'unité à une personne qui ne sait pas comment faire cela. Cela vient de perdre du temps. Mener par l'exemple. Progressivement.
Il a commencé après tout! ^ _ ^
J'ai eu une expérience très similaire il y a quelques années et tomba sur ce livre:
Il possède un ensemble incroyablement complet de techniques pour commencer par une base de code existante qui n'a pas de couverture de test unitaire et l'obtenir progressivement sous test. Si je pouvais recommander qu'un seul livre sur TDD, ce serait celui-ci.
Espérons que cela aide ... bonne chance!
Tyler
+1 intéressant. Mais ceci est une question générale, non spécifique aux rails. Cela vous dérangerait-il de le rehrasser?
Amit Kumar, pas de problème, ce faisant ça maintenant.
"Comment commencez-vous à écrire des tests unitaires sur une base de code existante - et de travail avec un temps limité?" Ceci est une question en double. Stackoverflow.com/search?q=%5bunit-testing%5D+legacy . Commencez par Stackoverflow.com/questions/1541568/ ...
Merci @s. Lott, cette question n'est pas liée (beaucoup). Celui-ci n'est pas connexe non plus Stackoverflow.com/Questions/748503/... Mais je serais heureux de trouver un qui est donc de la fermeture de celui-ci.
@yar: S'ils ne sont pas liés, puis corrigez votre question à indiquer clairement comment ces autres - existantes - les questions identiques ne sont pas identiques. Veuillez identifier des détails spécifiques qui rendent votre question différente.
@S. Lott: L'autre question pose: "Avez-vous déjà fait cela, à quel point était-ce difficile, et cela valait-t-il la peine." Je demande comment ajouter des tests d'unité à une base de code existante avec une durée limitée. Mais je vais réviser mon titre, encore une fois.
@YAR: La réponse acceptée dit "Le meilleur moyen, j'ai trouvé, est d'ajouter progressivement les tests de l'unité, de ne pas sauter et de dire que nous allons maintenant tester la demande" et références Stackoverflow .Com / Questions / 748503 / ... . On dirait que c'est votre réponse.
@S. Lott, oui tu es à 100% à droite. S'il vous plaît n'hésitez pas à marquer la question de la fermeture.