Si vous (ou votre organisation) aspirez à tester votre code de manière approfondie, comment mesurez-vous le succès ou la qualité de vos efforts?
Mon conseil n'est pas un moyen pour déterminer si vous avez de bons tests unitaires en soi, mais c'est un moyen de grandir un bon test de la suite au fil du temps.
Chaque fois que vous rencontrez un bug, soit dans votre développement ou signalés par quelqu'un d'autre, le fixer à deux reprises. Vous créez d'abord un test unitaire qui reproduit le problème. Quand vous avez un test en échec, puis vous aller et corriger le problème.
Si un problème était là en premier lieu c'est un indice sur une subtilité sur le code ou le nom du domaine. Ajout d'un test pour qu'il vous permet de vous assurer qu'il ne va jamais être réintroduit dans l'avenir.
Un autre aspect intéressant de cette approche est qu'il va vous aider à comprendre le problème à partir d'un niveau plus élevé avant de vous rendre et de regarder la complexité du code.
Aussi, +1 pour la valeur et les pièges de la couverture de test, déjà mentionné par d'autres.
La couverture de code est une métrique utile mais doit être utilisée avec précaution. Certaines personnes prennent la couverture de code, en particulier le pourcentage couvert, un peu trop au sérieux et la considèrent comme LA métrique pour de bons tests unitaires.
Mon expérience me dit que plus important que d'essayer d'obtenir une couverture à 100%, ce qui n'est pas si facile, les gens devraient se concentrer sur la vérification des sections critiques couvertes. Mais même dans ce cas, vous pouvez avoir des faux positifs.
Je suis très pro-ATS, mais je n'ai pas tellement d'importance dans la couverture des statistiques. Pour moi, le succès et l'utilité des tests unitaires est estimé sur une période de temps de développement par l'équipe de développement, comme les tests (un) découvrir des bugs à l'avant, (b) permettent de refactoring et de modifier sans régression, (c) permet d'étoffer modulaire, découplée de la conception, (d) et autres joyeusetés.
Ou, comme Martin Fowler, l'preuves empiriques à l'appui de tests unitaires et TDD est écrasante, mais vous ne pouvez pas mesurer la productivité. Lire plus sur son bliki ici: http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
Pour atteindre une pleine mesure de la confiance dans votre code que vous avez besoin de différents niveaux de tests: unitaires, d'intégration et fonctionnels. Je suis d'accord avec les conseils donnés ci-dessus que les états que les essais devraient être automatiques (intégration continue) et que les tests unitaires doivent couvrir toutes les branches à une variété de cas de bord ensembles de données. Les outils de couverture de Code (par exemple, Cobertura, Trèfle, EMMA etc) permet d'identifier des trous dans tes branches, mais pas dans la qualité de votre essai des ensembles de données. L'analyse statique de code comme FindBugs, PMD, la formation continue peut identifier les zones à problème dans votre code avant qu'ils ne deviennent un problème et aller un long chemin vers la promotion de meilleures pratiques de développement.
Les essais doivent tenter de reproduire l'ensemble de l'environnement que l'application va être en cours d'exécution dans la mesure du possible. Il devrait commencer à partir de la plus simple possible (unité) à la plus complexe (fonctionnelle). Dans le cas d'une application web, l'obtention d'un processus automatisé dans tous les cas d'utilisation de votre site web avec une variété de navigateurs est un must si quelque chose comme SeleniumRC devrait être dans votre boîte à outils.
Cependant, il existe des programmes pour répondre à un besoin de l'entreprise il y a donc aussi des tests contre les exigences. Ceci tend à être plus d'un manuel de processus, sur la base fonctionnelle (web) des tests. Essentiellement, vous aurez besoin pour construire une matrice de traçabilité à l'encontre de chacune de ces exigences dans le cahier des charges et le test fonctionnel. Comme les tests fonctionnels sont créés, ils sont jumelés contre l'une ou plusieurs des exigences (par exemple, la Connexion comme Fred, mettre à jour les détails du compte pour un mot de passe, vous déconnecter à nouveau). Cela répond à la question de savoir si ou non le produit correspond aux besoins de l'entreprise.
Dans l'ensemble, je serais partisan d'un développement piloté par les tests approche basée sur certains saveur de traitement automatisé de tests unitaires (JUnit, nUnit, etc). Pour les tests d'intégration, je vous recommande de vous constituer une base de données de test qui est rempli automatiquement à chaque build avec un ensemble de données qui illustre cas d'utilisation courante, mais qui permet à d'autres tests pour construire sur. Pour les tests fonctionnels, vous aurez besoin d'une sorte d'interface utilisateur robot (SeleniumRC pour le web, l'Abbé pour le Swing, etc). Des mesures concernant chacun peut facilement être recueillies pendant le processus de construction et affiché sur le serveur CI (par exemple Hudson) pour tous les développeurs à voir.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
