Promouvoir les tests 4/5. Gestion des données de tests et choix des outils

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

Gestion des données

Pour résumer, l’objectif est ici de placer la BDD dans un état prédéfini avant le test, de façon automatique, afin d’assurer sa reproductibilité. De plus, cette initialisation doit se faire :

  • de façon suffisamment rapide pour que la durée d’exécution des tests ne devienne pas une contrainte ;
  • de façon suffisamment souple pour injecter facilement toutes sortes de données. En outre, une méthode d’insertion dynamique permettra par exemple de créer des listes volumineuses pour tester un composant de pagination ou de tri.

Les tests contextuels nécessitent des jeux de données plus conséquents que les tests en isolation. Malgré tout, il est important que ceux-ci restent suffisamment légers pour conserver des performances acceptables.

Pour organiser ces jeux de données de façon optimale, nous distinguerons :

  1. La structure de la BDD ;
  2. Les données de référence, qui se trouvent dans des tables qui ne sont jamais modifiées lors de l’utilisation habituelle de l’application. Exemples: Table “CIVILITE” (Mr, Mme, Mlle), table des départements, etc.
  3. Les données d’initialisation, nécessaires au fonctionnement de l’application. Exemple: l’administrateur déclaré dans la table des utilisateurs ;
  4. Les données de tests génériques. Il s’agit de jeux de données significatifs relativement réduits, permettant de répondre à un ensemble de cas de tests. En général, nous aurons plusieurs jeux de données (par exemple : un par domaine fonctionnel) afin de garder des jeux relativement réduits et suffisamment rapides à insérer en BDD ;
  5. Les données de tests spécifiques. Il s’agit de données nécessaires à un test précis qu’il n’est pas souhaitable de partager avec les autres tests, car elles en réduiraient la vitesse d’exécution. Exemple : insertion d’un grand nombre d’utilisateurs pour tester un composant de pagination ou de tri.

Choix des outils

La nature des jeux de données et la façon dont ils seront insérés en base peuvent varier selon les outils.

Par exemple, le DB-Maintainer d’Unitils permet de gérer des jeux de données écrits en SQL. En lui adjoignant une méthode d’insertion en JAVA, nous pouvons implémenter la stratégie suivante :

  1. La structure de la base et les données de référence sont gérées dans un ou plusieurs scripts SQL. Le DB-Maintainer assure la synchronisation entre ces scripts et la BDD du développeur.
    • la modification d’un script entraîne la réinitialisation “from scratch” de la BDD du développeur.
    • l’ajout d’un script est pris en compte de façon incrémentale.
  2. Les données d’initialisation sont insérées avant chaque test. Elles sont gérées dans un ou plusieurs scripts SQL. Pour chaque test, les scripts à utiliser sont spécifiés par annotations.
  3. Les données de tests génériques sont également insérées avant chaque test. Afin d’obtenir une souplesse suffisante, elles sont insérées en JAVA, typiquement via les DAO de l’application. Cela apporte l’énorme avantage de survivre au “refactoring” ! Ces jeux de données sont donc exprimés sous forme de classes Java et l’on choisira ici aussi pour chaque test ceux qui sont nécessaires.
  4. Les données de tests spécifiques sont insérées au début de la méthode de test elle-même.

Le schéma suivant illustre la mise en œuvre de cette stratégie. Les types de données cités ci-dessus sont indiqués par leurs numéros :

Gestion des donnees de test

Gestion des donnees de test

Le fait d’utiliser uniquement du SQL (en petite quantité) et du JAVA réduit les coûts de formation. Cela dit, pour les inconditionnels du XML, LiquiBase devrait permettre d’obtenir un comportement similaire. Je n’ai pas encore eu l’occasion de tester cet outil.

Ici, Spring est utilisé en sa qualité de “micro-container” pour s’abstraire du serveur d’application.

Pour assurer la reproductibilité des tests, il est important que les données fassent partie intégrante du projet et qu’elles soient versionnées avec lui.

m4s0n501

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>