En découvrant les nouvelles fonctionnalités de GreenPepper 2.6 j’ai eu envie de les partager au plus vite ! GreenPepper autorise maintenant une syntaxe très flexible pour exprimer des scénarios (ou cas d’utilisation) dans un formalisme qui peut être défini en collaboration entre les experts métiers et développeurs. Le mot–clef associé à cette syntaxe est « scenario ». Je vais vous montrer dans ce billet comment utiliser GreenPepper pour exprimer des exigences sous la forme « Given, When, Then », formalisme recommandé par le courant « Behaviour Driven Developpement ».
Un cas concret à spécifier
Prenons un cas concret d’exigences fonctionnelles. Spécifions le comportement d’un agent virtuel d’assistance, dont le rôle est de répondre à des demandes d’aide en trouvant des interlocuteurs pouvant satisfaire les demandes d’aide.
Les principales « user stories » seraient les suivantes :
- En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, j’interpelle l’agent virtuel afin de lui décrire mon problème.
- En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, je souhaite contacter une personne disponible et disposée à m’aider.
- En tant qu’utilisateur pouvant apporter mon aide, je souhaite être contacté par l’agent virtuel afin de proposer mon aide.
Reformulons maintenant sous la forme d’exemples certains cas d’utilisation :
| Etant donné que Marc n’a jamais contacté l’agent virtuel |
| Quand Marc dit à l’agent virtuel « Hello », |
| Alors l’agent virtuel lui répond « Que puis-je faire pour t’aider ? » |
| Quand Marc dit à l’agent virtuel « Je n’arrive pas à installer Credanse+ sur MacOS » |
| Alors l’agent virtuel lui répond « J’ai bien pris note de ta demande d’aide et te contacte dès que possible » |
| Etant donné que Marc a déjà formulé la demande d’aide « Je n’arrive pas à installer Credanse+ sur MacOS » |
| Etant donné que Steve est disponible |
| Etant donné que Marc n’est pas disponible |
| Quand l’agent virtuel contacte Steve pour lui dire « Marc a besoin d’aide, il m’a dit : Je n’arrive pas à installer Credanse+ sur MacOS . Acceptes-tu de l’aider ?» |
| Quand Steve dit à l’agent virtuel « Oui » |
| Alors l’agent virtuel lui répond « Merci, je vais en faire part à Marc et il te contactera dès que possible » |
Spécifier dans GreenPepper
Voyons comment écrire le premier scenario avec GreenPepper :
Dans notre espace collaboratif d’édition de spécifications (Confluence ou XWiki), nous saisissons le tableau suivant :
Mettons un peu de couleur pour faire mettre en relief ce qui relève de la syntaxe et ce qui est en rapport avec les données du scénario.
Coder la classe de test
Maintenant, nous devons écrire la classe de test (ou fixture). Une première implémentation naïve de cette classe pour faire passer le test est :
public class AgentVirtuel
{
private string lastwords = “”;
private string lastuser = “”;
public AgentVirtuel()
{
}
[Given("Quand (\w+) dit à l'agent virtuel ([\w|\s|\'|\-|\?]*)”)]
public void WhenUserTellsTheAgent(string userName, string words)
{
lastwords = words;
lastuser = userName;
}
[Then("Alors l'agent virtuel répond ([\w|\s|\'|\-|\?]*)”)]
public void ThenTheAgentAnswers(Expectation answer)
{
if (lastwords==“Hello”)
{
answer.Actual = “Que puis-je faire pour t’aider?”;
}
else
{
answer.Actual = “J’ai bien pris note de ta demande d’aide et te contacte dès que possible”;
}
}
}
Dans cet exemple C# (il est possible d’écrire la même fixture en Java avec GreenPepper), nous voyons des attributs en charge de gérer la correspondance entre chaque « phrase » du scénario et une méthode de la classe de test.
Le mot-clef « Given » permet de définir ou d’initialiser un comportement qui ne sera pas testé. Par contre, le mot-clef « Then » permet de déclarer des attentes et de les tester. Dans cet exemple, nous testons la réponse de l’agent virtuel.
Exécuter la spécification
Exécutons notre spécification avec GreenPepper et observons le résultat :
Après exécution, une confirmation visuelle affiche automatiquement en vert les parties de texte qui ont été vérifiées positivement par GreenPepper. En cas de confirmation négative, la couleur rouge sera utilisée.
En conclusion…
Nous voyons à travers cet exemple, que l’utilisation d’expressions régulières associées à des méthodes de la classe de test, permet une grande souplesse ! Aux équipes de jouer et de trouver une syntaxe qui facilitera une compréhension partagée entre toutes les parties prenantes du projet ! Cette compréhension partagée sera de plus testable en continue!
My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.
