Tags

, , , , , ,

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests” apply_16x16-32
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Développement piloté par les tests

L’engouement pour les techniques “Agiles”, et plus particulièrement l'”Extreme Programming” a conduit de nombreux informaticiens à se demander si les méthodes TDD — “Test Driven Design” ou “Test Driven Development” — ne seraient pas la solution pour enfin promouvoir les tests dans leurs projets. En effet, en substituant l’approche traditionnelle “Coder-Tester-Déboguer” par l’approche “Tester-Développer-Remanier”, le TDD place les tests au cœur du processus de développement.

Mais ce qui rend délicat son adoption, c’est qu’il s’agit avant tout d’une méthode de conception “Agile”, à laquelle l’équipe projet doit être formée. Cette méthode a pour objectif premier de réduire les cycles de livraison. En codant le strict minimum requis entre chaque cycle, on évite les incompréhensions et l’on peut s’adapter aux changements.

Le cycle de développement préconisé est le suivant :

  1. écrire un test ;
  2. vérifier que ce test échoue ;
  3. écrire juste le code suffisant pour passer le test ;
  4. vérifier que le test passe ;
  5. remanier le code pour l’améliorer tout en gardant les mêmes fonctionnalités.

Aujourd’hui, le TDD a fait ses preuves pour assurer la robustesse de frameworks et APIs techniques. Par contre, sa capacité à améliorer la productivité sur un projet Java EE reste très controversée. En particulier l’argument selon lequel le temps passé à développer les tests serait compensé par la capacité de l’application à évoluer sans régression (et par la qualité obtenue en général) n’est pas partagé par tous les directeurs de projets.

Toujours est-il que, malgré tous les avantages du TDD,  ce n’est sûrement pas la solution appropriée si l’on ne dispose pas d’une équipe spécialement formée. De même, si l’objectif recherché est uniquement de promouvoir les tests sans remettre en cause les méthodes de travail, le choix TDD est trop radical.

Développement assisté par les tests

Sans bouleverser les méthodes de travail existantes, une solution efficace pour encourager l’écriture et l’emploi de tests consiste à en faire un outil apprécié des développeurs… car en matière de tests unitaires, ce sont les premiers concernés.

Pour y parvenir, les objectifs à atteindre dans le contexte du développement d’une application de gestion sont les suivants :

  • les tests unitaires (TU) doivent aider les développeurs à valider le comportement de leur code ;
  • ils doivent leur permettre de faire évoluer l’application en minimisant les risques de régression. Ce sont en grande partie des tests de non-régression ;
  • ils doivent être exécutés fréquemment pour détecter au plus tôt les régressions, et en faciliter la résolution ;
  • ils doivent faire gagner du temps aux développeurs en fournissant une alternative au processus de test “manuel” habituel qui consiste à démarrer un serveur, puis à parcourir les écrans de l’application pour atteindre la fonction que l’on souhaite tester ;
  • ils doivent être reproductibles afin d’être aisément exécutables par tous, ainsi que par le serveur d‘intégration continue.

La plupart de ces principes sont présents en TDD, mais ici, le test n’est pas imposé par la méthode de conception. Il s’impose en tant qu’outil de développement.