Tests d'acceptation orientés comportement

Voire même Behaviour Driven Development

Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système.

Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs.

Pour décrire les tests d’acceptation, ma préférence va à une technique orientée comportement, le BDD.

Chaque test est décrit par son état de départ, l’événement déclenchant la story, et son état d’arrivée, avec le formalisme suivant[1] :

  1. Étant donné le contexte et la suite du contexte
  2. Quand l’événement
  3. Alors résultat et autre résultat

Cette façon de faire est particulièrement adaptée à des applications dites event-driven(par opposition à data-driven). Elle pousse à avoir des tests courts, puisqu’on y décrit la réponse à un seul événement.

Exemple sur un test Vérifier que le retrait n’est pas autorisé si le solde est inférieur à - 500 :

  1. Étant donné un compte 67890 avec un solde initial de 0 et un client C possesseur du compte
  2. Quand le client C fait un retrait de 600 sur le compte 67890
  3. Alors le retrait est refusé et le message « Vous n’êtes pas autorisé à retirer cette somme » est envoyé à C et le solde de 67890 reste à 0

Notes

[1] que j’avais déjà présentée dans un post Formaliser les critères d’acceptation, il y a presque un an

Voir aussi