#devoxxfr – JGiven

Bon, pour la BDD, j’ai déja vu Fitnesse, et franchement, ça fait braire tellement c’est mal fichu. J’avais aussi vu un autre outil BDD, bien plus convaincant, au chtijug, mais comme j’ai oublié son nom, ben forcément, c’est moins tentant.

Heureusement, c’est la fin de journée, et les talks raccourcissent. On est donc partis pour 1/2 heure de JGiven. Espérons que ce soit chouette !

Et donc, le BDD, ce sont les three amigos (dév, test, métier) qui écrivent ensemble les specs à partir d’exemple.

Le but de JGiven, c’est de produire un rapport facilement lisible et navigable.

Et effectivement, le rapport est beau. Bien plus beau que Cucumber … et je ne vous parle pas de l’horreur qu’est Fitnesse.

Encore mieux que le rapport, un scénario n’est pas un fichier plat, mais une classe Java (en fait un test). Et en bonus, quand on exécute le test, JGiven affiche un joli rapport d’exécution qui va contenir le scénario de façon lisible avec les succès ET les échecs.

Et attendez, c’est pareil pour injecter les valeurs des tests (plutôt que de faire des sales tables façon wikipedia) !

Bon, mais tout ça, c’était « simple ».

Quand on veut partager les informations, JGiven fournit aussi des outils pratiques.

bon, la présentation va vraiment vite. Donc on passe vite fait aux options de présentation, qui vont permettre d’afficher une variable du test entre guillemets de façon automatique, par exemple.

Franchement, pourquoi on n’utilise pas dans nos projets ce genre d’outils intelligents, mais des horreurs comme Fitnesse ?

Je note toutefois qu’un outil comme JGiven n’est en fait qu’un support de discussion.

Et c’est vrai qu’avec un outil pareil, aller voir le métier pour discuter d’un point d’implémentation est vraiment pratique.

Question marrante : comment le métier écrit les scénarios.

La réponse est chouette : en fait, le métier n’écrit pas les scénarios – ils le font peut-être au début, mais très rapidement, il faut être développeur pour pouvoir maintenir un scénario. Du coup, le fait que ce soit en fait simplement une surcouche de JUnit n’est pas gênant sur le long terme. Ce qui s’illustre par le processus de développement : le BI arrive avec une idée, qui est élicitée par l’équipe de dév à grands coups de post-it. Puis, une fois la réunion terminée, les post-its sont traduits directement en code (parce qu’ils sont valides).

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s