Stratégies de test

Tests façon BDD

Dans le cadre de behaviour-driven development (BDD), le terme « spécifications » va être préférable au terme « tests ». L’idée est de rapprocher l’élaboration des tests unitaires de l’élaboration des tests fonctionnels, et d’impliquer fortement les experts du métier dans l’écriture des tests.

L’élaboration des scénarios de test repose grandement sur le canevas Given-When-Then :

  • (Given) (Etant donné) un contexte,
  • (When) (Lorsque) certaines actions sont effectuées,
  • (Then) (Alors) on doit constater tels résultats.

Par exemple :

  • (Given) Il reste un seul Mon Chéri dans la boîte,
  • (When) Je prends un Mon Chéri,
  • (Then) La boîte de Mon Chéri est vide.

Test doubles

Par le terme test double, on désigne une partie du test automatique qui va simuler un composant ou sous-système supposé exister dans la vie réelle. Cela permet de concentrer le test sur les composant à tester, en supposant le bon fonctionnement des composants qui interagissent avec ce dernier.

Gerard Meszaros, dans son ouvrage xUnit Test Patterns, fournit une classification des test doubles :

  • les dummy objects, ce sont des objets qu’on peut passer en argument mais qui ne sont pas utilisés en tant que tels; on les utilise en général pour remplir des listes de paramètres ;
  • les fake objects, ces objets ont une implémentation dédiée au scénario de tests, ils ne seraient pas utilisables directement en production (ex : service de gestion des droits simplifié, ou base de données en mémoire) ;
  • les stubs,  ils fournissent des réponses pré-programmées aux appels faits pendant le test ;
  • les spies, ce sont des stubs particuliers qui enregistrent également des informations sur leurs appels, ce qui permet de savoir combien de fois ils ont été appelés, ou avec quels paramètres ;
  • les mocks, qui sont programmés avec des valeurs attendues en fonction des paramètres fournis (dès qu’ils sont appelés avec les valeurs de paramètres décrites, la valeur programmée est automatiquement renvoyée) ; on peut même les programmer pour lever une exception si nécessaire.

Les tests doubles sont particulièrement adaptés à la réalisation de tests unitaires, dans la mesure où le composant testé ne repose plus sur le comportement, potentiellement fluctuant, des composants dont il dépend. Les tests doubles auront en effet toujours le même comportement, conforme à la spécification des composants auxquels ils se substituent (même si leur implémentation réelle évolue). En cas de d’échec du test unitaire, la qualification du problème est grandement facilitée, on sait que le composant testé est directement en cause et ne subit aucun effet de bord externe.

En contrepartie, les composants en interaction avec le composant testé ne sont plus directement testés : ils doivent au choix également être accompagnés de leurs propres tests unitaires, ou participer à des tests d’intégration plus globaux.

Laisser un commentaire