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] :


Etant donné le contexte et la suite du contexte

Quand l'événement

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 :


Etant donné un compte 67890 avec un solde initial de 0 et un client C possesseur du compte

Quand le client C fait un retrait de 600 sur le compte 67890

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