Pourquoi les développeurs n'aiment pas Behat ?

Depuis sa mise à disposition, Behat est un outil plutôt controversé de la part des développeurs. Il y a ceux qui l’aiment et ne peuvent s’en passer (c’est mon cas) et ceux qui bien au contraire le détestent. Pourtant Behat est un outil formidable qui permet de faire le lien entre les tests d’acceptations et l’application que l’on est en train de concevoir. Tout cela de manière automatisée. Dit autrement, il va permettre de valider qu’une demande exprimée en langage métier donne le résultat attendu. Pourtant, je rencontre très souvent des développeurs qui ne supportent pas cet outil. J’ai tenté de comprendre pourquoi.

Avant de tenter de répondre à cette question, je pense qu’il est nécessaire de comprendre comment fonctionne l’outil. Comme évoqué précédemment, un des plus grands intérêts de Behat est que l’on va exprimer le test en langue naturelle (peu importe la langue utilisée). Le format d’écriture ressemble beaucoup à l’expression d’une user-story utilisé dans la méthode SCRUM.

Voici par exemple un exemple de scénario :

# language: fr
Fonctionnalité: Avoir un compte bancaire
    Afin d'offrir aux utilisateurs la possibilité d'avoir un compte bancaire
    Etant donné que je suis inscrit
    Je dois être capable d'ajouter ou de retirer de l'argent sur mon compte

    Scénario:
        Etant donné que je suis un utilisateur connecté
        Et que j'ai un compte bancaire
        Et que le solde de mon compte est de "10" euros
        Quand j'ajoute "5" euros sur mon compte
        Alors mon solde doit être de "15" euros

Lorsque l’on écrit nos tests Behat, nous commençons par décrire la fonctionnalité de manière générale puis on décrit un ensemble de cas d’utilisation. Ces derniers vont alors définir un contexte d’exécution, une série d’événements et terminer par le résultat attendu.

Les scénarios Behat peuvent ensuite être exécutés dans un ou plusieurs environnements. Par exemple, dans le cas d’un site Web, il est tout à fait envisageable d’exécuter le scénario dans différents navigateurs pour valider que le fonctionnement de l’application est correct aussi bien sur Firefox que Chrome ou Internet Explorer.

Une fois les scénarios écrits, il faudra alors que le développeur fasse le lien entre les étapes des différents scénarios et les actions qui en résultent dans l’application. Heureusement, Behat nous aide dans cette tâche en prégénérant le squelette du code correspondant.

Avec ce que nous venons dire, ne trouvez-vous pas que Behat est un outil extrêmement intéressant ? Il nous permet :

• De valider notre compréhension du besoin client
• De valider que notre application réponde correctement à ce dernier
• De documenter notre application et fournit un esemble de spécifications

Alors pourquoi un développeur peut ne pas aimer Behat ?

Comme l’explique son auteur. Avec Behat, un développeur ne teste pas son application, mais il s’assure que son application réponde aux besoins métiers de son client. Beaucoup d’applications répondent aux attentes des développeurs, mais peuvent ne pas couvrir les besoins métiers.

Toujours d’après son auteur, Behat permet en réalité d’apprendre au développeur comment fonctionne le métier du client.

Je pense que si beaucoup de développeurs n’aiment pas Behat c’est à cause de ce dernier point. Ecrire des bons scénarios Behat est un travail délicat. Il faut exprimer le métier du client et non pas le fonctionnement de l’application.

Un développeur aura facilement tendance à écrire ce genre de scénario :

# language: en
Scenario: Showing delivery cost for a product on the basket page
  Given there is a product:
    | name  | White Marker |
    | price | £5           |
  And I am on the "/catalogue" page
  When I click "Buy" in the "White Marker" product block
  And I go to the "/basket" page
  Then I should see a list with 1 product
  And the overall price should be shown as £9

Alors que le scénario exprimé du point de vue du client devrait ressembler à :

# language: en
Scenario: Getting the delivery cost for a single product under £10
  Given a product named "White Marker" and priced £5 was added to the catalogue
  When I add the "White Marker" product from the catalogue to the picked up basket
  Then the overall basket price should be £9

Mais adopter ce point de vue n’est pas évident pour un développeur, qui a souvent plus une vision technique que fonctionnelle de l’application. Cela demande donc un véritable effort de réflexion, en plus de devoir écrire le code correspondant aux différents scénarios.

Je reste donc persuader que si de nombreux développeurs n’aiment pas Behat, c’est essentiellement à cause de leur culture technique et qu’il est difficile pour eux de faire un volte-face pour se mettre à la place du client.

Il se peut aussi que comme j’avais tenté de l’expliquer dans un précédent billet, que les développeurs vont tenter de se lancer directement dans l’écrire de leurs scénarios Behat, sans prendre le temps de comprendre les outils qu’ils utilisent et la manière de le configurer correctement.

Ressources :

• Behat by example
• Introducing Modelling by Example