Ce billet démarre une série consacrée à cet outil que je trouve génial : Behat. Désolé pour la longueur, mais le sujet est suffisamment intéressant à mon goût pour être creusé comme il faut. :-)

Pour ce premier jour avec Behat, on va se placer du côté du client uniquement. la partie développeur viendra dans le prochain billet. Nous allons donc découvrir Behat pas à pas.

Behat, c'est quoi ? Pour le comprendre, il faut d'abord faire un tour du côté des méthodes agiles, et particulièrement du côté de SCRUM

Scrum - la notion de produit et de test d'acceptation

Scrum, c'est avant tout un état d'esprit, mais c'est aussi un exemple d'organisation. Imaginez un peintre à qui l'on demande de peindre Mona Lisa. Si on fait l'analogie avec le développement, la manière classique consiste à peindre le tableau de haut en bas, comme le ferait une imprimante. Le tableau ne pourra être livré qu'une fois la peinture entièrement achevée, de bas en haut.

Au contraire, en Scrum, on va commencer par esquisser les traits de Mona Lisa, puis on va demander au client si ça lui convient. Puis on va affiner le trait et le dessin. On redemande au client si ça lui convient. Enfin on va pouvoir ajouter des touches de couleurs, etc. C'est ce qu'on appelle un développement itératif. A chaque itération ("release"), le client valide le produit fourni et décide ou non de continuer. S'il s'arrête, le produit est simplement moins riche qu'escompté, mais il est livrable et utilisable par le client.

En Scrum, le client est donc le maître du produit qu'on lui fourni : il a la main dessus et doit participer activement a sa description fonctionnelle. On dit alors qu'il est le propriétaire du produit (Product Owner).

Pour décrire, justement, son produit, le client fourni généralement des spécifications fonctionnelles détaillées (SFD - qui, au passage, ne sont en général jamais lues car trop longues). Cette fois le client va au contraire décrire des cas d'utilisation de son produit. Pour savoir si le produit livré correspond à son besoin, il lui suffira de s'assurer que les cas d'utilisation sont respectés. Ces cas d'utilisation, garants du produit, sont regroupés dans tests d'acceptations du produit.

A chaque itération (release), le produit livré est donc comparé au produit souhaité au moyen de ces tests d'acceptation. C'est la garantie :

• de satisfaire la demande initiale du client
• d'éviter les quiproquos ("mais moi je voulais pas ça")
• d'éviter les spécifications trop volumineuses
• d'éviter l'ajout de nouvelles fonctionnalités par le client au fur et à mesure du développement (mais il pourra ajouter des fonctionnalités lors d'une prochaine release)

Behat dans tout ça ?

Behat, c'est l'outil PHP qui va permettre de faire le lien entre ces tests d'acceptation, écrits par le Product Owner, et le produit que moi, développeur, je lui livre. Bien plus, il permet de lancer ces tests d'acceptation de manière automatisée sur le produit et d'en fournir un rapport lisible par n'importe quel client. A chaque release, en un coup d'oeil, le client voit si ce qu'on lui a livré correspond à son besoin.

Attention ! Behat ne se substitue pas aux tests unitaires. Non, au contraire. Ce qu'il faut se dire c'est que le client n'en a rien à faire de savoir que le code est de bonne qualité ; ce qu'il veut c'est un produit fini, fonctionnel, conforme à ses souhaits initiaux. Le test unitaire, lui, va nous permettre de nous assurer de l'intégrité du code pour des fonctionnalités sensibles ou complexes. Il ne teste pas le comportement du produit (mais le test unitaire reste cependant indispensable)

Le développeur a en effet souvent tendance à détourner ses tests unitaires de leur fonction initiale (tester du code), pour tester des scénarios (par exemple qu'un Controlleur a le comportement attendu). Ce n'est pas aux outils de tests unitaires de faire cela. Heureusement, Behat est là pour ça ;-) !

Comment ça marche ?

Bon, c'est bien, mais plus concrètement ça marche comment ?

Et bien le Product Owner va rédiger ses tests d'acceptation en langue naturelle. Chaque fonctionnalité va être écrite dans un .

Il commencer par une description de sa fonctionnalité :

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

Cette description permet de comprendre la fonctionnalité de manière générale. Ensuite il va fournir des cas d'utilisation qui vont décrire cette fonctionnalité. On parle alors de "Scénario". Chaque scénario est défini par :

• un contexte (étant donné que)
• des événements déclencheurs (quand)
• un résultat attendu (alors)

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

Il va pouvoir combiner les scénarios :

Scénario:
  Etant donné 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

<p>Scénario:</p>
  Etant donné que j'ai un compte bancaire
  Et que le solde de mon compte est de "10" euros
  Quand je retire "50" euros sur mon compte
  Alors je dois avoir le message d'erreur "vous n'avez pas le droit d'être à découvert"
  Et mon solde doit être de "10" euros

Quand je lancerai Behat, si mon application fonctionne correctement, ce scénario va être valide et donc coloré en vert à l'écran.Sinon il sera rouge.

Mieux encore, le Product Owner va pouvoir insérer des exemples. Behat va automatiquement lancer ces tests pour chaque exemple fourni :

Scénario Outline:
  Etant donné que j'ai un compte bancaire
  Et que le solde de mon compte est de "" euros
  Quand j'ajoute "" euros sur mon compte
  Alors mon solde doit être de "" euros

  Examples:
    | soldeInitial | montant | soldeFinal |
    | 5            | 10      | 15         |
    | 20           | 20      | 40         |
    | 20           | 7       | 27         |
    | 0            | 10      | 10         |

Pas mal non ? Je vais avoir un rapport visuel (une page web par exemple) de l'état de mon produit par rapport à ces tests :

Maintenant vous avez compris le principe du test d'acceptation. Vous vous êtes mis dans la peau d'un Product Owner qui rédige ses tests d'acceptation. Si vous êtes Product Owner, vous n'avez pas besoin d'aller plus loin. Si vous êtes développeur ou Scrum Master, on verra ensemble le versant technique de Behat dans le prochain Billet ;-)

Edit: le jour 2 est prêt : Behat – jour 2 : Installation et premiers tests