Comment écrire de bons tests. Top 5 pour construire des logiciels sans défaut.
Auteur : Alberto Gutierrez
Source : How to write good tests. Top 5 considerations to build software without defects
Date : 05/08/2009
Traducteur : Fabrice Aimetti
Date : 11/08/2009
Traduction :
Le Test a été considéré (et est encore considéré dans certaines entreprises) comme la dernière étape du développement de logiciels, les développeurs espéraient qu’ils allaient construire leurs applications à partir de zéro et sans erreurs, de sorte que la phase de test serait une simple formalité où seules des erreurs mineures apparaîtraient, heureusement, nous passons de cette utopie à un nouveau concept où le Test fait partie intégrante du processus de développement.
Ce qui suit est un extrait des "meilleures pratiques" illustrant ce nouveau paradigme du Test.
Sommaire
- 1 Tester le code est aussi important que produire du code.
- 2 Testez autant que possible, testez dès que possible, testez le plus souvent possible.
- 3 Testez à différents niveaux.
- 4 Le Test fait partie intégrante du process de développement. Intégration continue.
- 5 Utilisez des outils de tests et des frameworks.
Tester le code est aussi important que produire du code.
Une des raisons les plus courantes d’échouer pour les équipes se mettant au TDD est que leurs tests ne sont pas codés proprement, cela peut donc coûter plus cher de maintenir des tests que d’écrire le code du produit logiciel, afin d’éviter ce scénario, il est important de garder à l’esprit qu’avoir des tests codés proprement est aussi important que d’avoir un produit codé proprement.
Réutilisez les spécifications de contenu des tests (fixtures). Si vous avez besoin de certaines données pour mener différents tests, rendez les réutilisables et disponibles en un seul endroit.
Écrivez vos propres assertions. Si vous testez des données dans 5 scénarios différents, et si vous voulez prouver que tout fonctionne bien pour chacun des scénarios, vous avez besoin de 5 assertions différentes, écrivez donc votre propre assertion qui effectue les 5 autres et appelez-la depuis votre code, au lieu d’écrire 25 assertions différentes.
En général, utilisez les mêmes principes que ceux que vous appliquez pour écrire le code de votre produit logiciel : dans cet autre billet, vous trouverez plus d’indications pour écrire du bon code: 10 commandements pour écrire un bon code.
Pour aller plus loin, je vous recommande fortement la lecture du livre suivant: "xUnit Test Patterns: Refactoring Test Code".
Testez autant que possible, testez dès que possible, testez le plus souvent possible.
Comme je l’ai dit dans mon précédent billet, je suis un développeur TDD convaincu, mais peut-être ne l’êtes vous pas, ce qui est important est que peu importe si vous écrivez le test avant ou après, vous ne devez pas écrire de nouveau code avant d’avoir un test qui prouve que le code que vous venez d’implémenter fonctionne comme prévu. Cette habitude de tester autant que possible, dès que possible et aussi souvent que possible, vous empêchera de créer de nouveaux bugs dans le système, et cela vous rendra donc également plus confiant et plus productif.
Testez à différents niveaux.
N’essayez pas d’écrire des tests qui couvre aussi bien l’IHM que le "backend", cela prend trop de temps à écrire, c’est difficile à maintenir, c’est lent à exécuter, c’est également très difficile de tester tous les différents éléments de votre application si vous ne les avez pas séparé, la meilleure approche est de tester à différents niveaux. Envisager d’avoir au minimum la série de tests suivante :
Tests unitaires. Tests qui vérifient tous vos composants séparément, sans tenir compte de leurs interactions avec d’autres composants.
Tests d’acceptance. Spécifiés par le Product Owner, ces tests représentent le minimum de fonctionnalités que l’application doit fournir pour être accepté d’un point de vue métier.
Tests d’intégration. Ces tests ne sont pas identifiés par le Product Owner dans ses tests d’acceptance mais élaborés soit par l’Assurance Qualité soit par le développement.
Tests d’IHM. Les tests IHM sont lents, l’IHM est également susceptible de changer durant le développement et l’on doit donc réaliser des tests ciblés, en conservant les tests IHM séparés des tests backend nous ne serons donc pas impactés à chaque fois que l’IHM change.
Le Test fait partie intégrante du process de développement. Intégration continue.
Le Test doit faire partie intégrante du processus de développement, une chose n’est pas terminée tant qu’elle n’a pas été testée, oubliez le fait d’avoir une étape différente dans laquelle une personne se soucie des tests, tout le monde est responsable et validateur des tests : le développement, l’assurance qualité et le product owner. Idéalement, vous pourrez également mettre en place une intégration continue, qui dépasse le périmètre des tests, pour plus d’information sur l’intégration continue je vous renvoie sur cet excellent article de Martin Fowler.
Utilisez des outils de tests et des frameworks.
Heureusement, il existe un ensemble d’outils et de frameworks développés récemment pour nous aider à tester nos applications, une sélection de ces outils suit :
FitNesse. Un outil pour créer des tests d’acceptance, les non techniciens peuvent écrire leurs propres tests.
xUnit. Framework pour développer des tests unitaires, intégrés avec les plus populaires IDEs et langages de programmation.
CodeCover. Un plugin Eclipse pour la couverture de code, utile pour savoir quelles parties du code nous sommes en train de tester et celles qui ne le sont pas.
Jira. Un outil de reporting et de traçabilité, majoritairement utilisé pour tracer les bugs.
Mercury. Suite logicielle très connue, composée de différents outils pour différents types de tests, y compris les tests d’IHM.
Selenium. Outil de test d’IHM pour les applications web.
Hudson. Outil d’intégration continue, utilisé pour garantir que le code est toujours prêt à être livré et qu’il est passé à travers toutes les batteries de tests. Je ne résiste pas à ajouter ce dessin de CodeSmack :-)
