Cucumber vs les outils TDD/BDD

cucumber _ LOGO

 

Cucumber est un outil permettant de réaliser des tests automatisés. Ces tests sont écrits dans le style des BDD (Behavior-Driven development), on retrouve la story, les scénarios ainsi que les steps (given, when, then). Gherkin est le langage utilisé pour décrire les tests. Il a été conçu comme un langage non technique, c’est-à-dire compréhensible par toute personne. Il favorise ainsi la contribution de toute l’équipe en charge d’un projet.

Les autres outils et Cucumber

Dans notre exemple, nous voulons tester un service d’authentification.

Lorsque l’on écrit les tests avec la plupart des outils existants, ils ressembleront plus ou moins à ceci :

class AuthentificationTest {
   @Test
    public void testAuthentificationSucess() {
        // création d’un utilisateur "Bob" avec le mot de passe "Password"
        …
        // appel au service d’authentification avec l’utilisateur "Bob" et le mot de passe "Password"
        …
        // assertion de la réponse lors de l’appel du service d’authentification
        …
    }
}

On y retrouve une partie pour l’initialisation des données, l’exécution et la vérification des résultats d’exécution.

Lorsque l’on écrit un test avec Cucumber, ils ressemblent plutôt à ceci :

Feature: Système d’authentification

    Scenario: S’authentifier avec un utilisateur
        Given l’utilisateur "Bob" existe avec comme mot de passe "Password"
        When je m’authentifie avec l’utilisateur "Bob" et le mot de passe "Password"
        Then l’authentification est réussie
  • Le mot clé « Feature » permet de décrire notre use case de test.
  • Le mot clé « Scenario » permet de décrire notre scénario.
  • Les mots clés « Given », « When », et « Then » sont des « Steps » permettant l’initialisation, l’exécution et la vérification du « Scenario ».

D’un point de vue fonctionnel, ces deux exemples sont identiques. La différence est que celui écrit en Gherkin est beaucoup plus lisible.

Séparation des couches

Pour fonctionner, le test Cucumber s’appuie sur un fichier de définition dans lequel sont codées les actions décrites par les « Steps ». A première vue, on constate que le travail à fournir est plus important par rapport aux autres tests :

  • La création de la feature ainsi que les scénarios associés
  • L'implémentation des steps

Mais ce découpage permet la réutilisation des définitions de steps pour un scénario différent. D’une part, ces deux tâches peuvent être réalisées par des personnes différentes. De l’autre, la réalisation de la feature et des scénarios ne requière pas de compétences techniques particulières.

La réutilisation

Si nous reprenons l’exemple cité plus haut :

Feature: Système d’authentification

    Scenario: S’authentifier avec un utilisateur
        Given l’utilisateur "Bob" existe avec comme mot de passe "Password"
        When je m’authentifie avec l’utilisateur "Bob" et le mot de passe "Password"
        Then l’authentification est réussie

Nous aurons 3 définitions de steps dans notre fichier de définitions :

  • La création de l’utilisateur « Bob » avec comme mot de passe « Password »
  • L’exécution du service d’authentification avec comme utilisateur « Bob » et mot de passe « Password »
  • L’assertion que l’authentification est réussie

Ajoutons un nouveau scénario :

Feature: Système d’authentification

    Scenario: S’authentifier avec un utilisateur
        Given l’utilisateur "Bob" existe avec comme mot de passe "Password"
        When je m’authentifie avec l’utilisateur "Bob" et le mot de passe "123456"
        Then l’authentification est réussie
  • La premières step « Given » est identique au précédent scénario, la définition existante peut être réutilisée.
  • La deuxième step « When » est identique au précédent scénario à l’exception du mot de passe envoyé au service d’authentification. En réalité, la correspondance entre les steps et l’implémentation est faite par regex, il est possible d’y extraire les paramètres présents dans la description afin de les injecter au service d’authentification. De ce fait, les steps ne sont pas « statiques » et se comportent comme un appel à une fonction classique (fonction qui est décrite dans le fichier de définitions des steps). Le fichier de définition n’a pas besoin d’être enrichi d’une nouvelle définition, celle existante peut être réutilisée.
  • La troisième step « Then » est nouvelle dans notre feature. Il est ici nécessaire de décrire son comportement dans le fichier des définitions (nouvelle implémentation).

Conclusion

C’est génial, on devrait utiliser les tests Cucumber partout !

En fait, pas tout à fait. Si Cucumber permet de faire des tests fonctionnels complets, il n’est par contre pas recommandé de faire des tests unitaires avec. La multiplication des steps rend sa maintenance lourde et complexe. Il est préférable d’utiliser d’autres outils qui seront plus adaptés pour la réalisation des tests unitaires ou spécifiques.

L’utilisation de Cucumber est pratique lorsque l’on souhaite faire des tests fonctionnels sur un environnement donné (intégration, recette, production). La séparation des couches permet de réduire le nombre de lignes de code (ainsi que sa maintenance). Il permet également à une personne qui n’est pas issue de la technique de rédiger les tests fonctionnels (ce n’est pas totalement vrai dans la réalité – comprendre les regex à minima permet de réduire la duplication des steps).

En revanche, faire des tests Cucumber n’exclut pas de faire de bons tests unitaires !

Source :

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.