Tags

, , , , ,

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

En pratique, que l’on choisisse le TDD ou une autre méthodologie, la complexité majeure de mise en œuvre réside dans la gestion des données de tests. La problématique consiste à placer la base de données dans un état prédéfini, avant l’exécution de chaque test, de façon automatique.

Par ailleurs, la politique de gestion des données est déterminante pour choisir les outils appropriés.

En TDD, les tests unitaires sont réalisés en pure isolation. C’est-à-dire que chaque fonction est testée en l’isolant de son contexte d’exécution afin d’éviter toute interférence externe qui risquerait de compromettre le résultat du test. C’est pour cela que les implémentations “mock” comme EasyMock ou Mockito (Mockito in six easy examples) sont très utilisées en TDD. L’isolation réduit aussi considérablement le volume de données de tests à gérer. Des outils comme DBUnit et SpringUnit, qui permettent de spécifier en XML les données attendues en entrée et en sortie de chaque test, sont alors adaptés.

En dehors d’un contexte TDD, cette technique d’isolation peut bien sûr être utilisée. Mais l’un des objectifs du développement assisté par les tests consiste à limiter les contraintes. En leur permettant de tester “dans le contexte”, on offre plus de latitude aux développeurs. Bien sûr, cette politique requiert des outils adaptés pour gérer de plus gros volumes de données. Les outils s’appuyant sur un format XML par exemple ne sont pas très appropriés car ils sont en général assez verbeux, et impliquent, si le schéma vient à changer, une phase de mise à jour laborieuse.

Ainsi, nos TU “contextuels” doivent :

  • s’exécuter rapidement hors serveur d’application ;
  • garder les objets dans leur contexte, en les laissant notamment faire appel aux couches de plus bas niveau. Un test au niveau métier/service descendra jusqu’à la couche d’accès aux données ;
  • fournir une couverture de code importante compte tenu du nombre de tests écrits.
Tests unitaires contextuels

Tests unitaires contextuels

Les cas de test pertinents seront identifiés naturellement par les développeurs qui bénéficieront du confort des tests unitaires. Par exemple, pour la couche d’accès aux données, ils pourront tester rapidement une requête SQL ou HQL complexe. Les rapports de couverture de code permettront aussi d’identifier les portions de l’application les moins testées.

Advertisements