[ALM, Unit Tests, SpecFlow] Magically generate your Unit Tests from the Specifications !!

(Sorry not translated from my French Blog : http://blogs.codes-sources.com/thavo/. Google Translation will help you)

Ce serait le rêve de générer par magie ses tests unitaires à partir des specs avant même d’avoir écrit son_code ?

• A la fois on serait en TDD, qui est déjà un rêve pour une majorité d’entre nous. Vous avez déjà entendu d’un Directeur/Chef de projet “Oui, c’est super les TU… mais on n’a pas le budget, le temps, il y a plus prioritaire, etc…”
• A la fois nos TU pourraient être “écrits” par le “Business Analyst” ou Chef de projet, si c’était le cas.

BDD existe déjà depuis un bout de temps, mais je voulais parler d’un outil particulier que nous allons découvrir ci-dessous.

PS: Dans ce cas BDD pas comme “Base De Données”, mais comme Behaviour Development Driven).

Comment cela peut fonctionner dans une ALM TFS en mode Agile ??

1.  Le Chef de projet ou Business Analyst écrit les specs dans TFS en tant que User Story. Voici un exemple : 

2. Toujours le Chef de projet ou Business Analyst écrit les scénarii de validation de tests d’acceptance afin de valider la User Story précédente.
Pour cela, écrit dans un fichier texte *.feature (compatible avec le standard Cucumber-Gherkin syntax) sous Visual Studio 2010 pour disposer de l’IntelliSense !!.

PS1: il y aurait moyen de créer cela en tant que WorkItem puis générer ce fichier texte.
PS2:  Pour faire le lien avec Scrum, on peut comparer cela à la “Definition Of Done”, qui doit être composé d’éléments mesurables, donc vérifiable (pas du genre… lorsque l’on clic sur le bouton “OK”, l’écran doit s’afficher rapidement).

3. Ensuite, toute la magie intervient dès que l’on fait Ctrl-S pour “enregistrer” ce fichier. Cela génère près de 100 lignes de code de tests unitaires C# (de type MsTest, mais cela pourrait être aussi xUnit, NUnit, MbUnit). ”La magie” s’appelle SpecFlow !!

4. Enfin, on peut compiler le tout et lancer les Tests Unitaires. Ne pas paniquer, si cela ne passe pas, puisque cela respecte bien le principe de TDD se basant sur le “RGR” (Red GreenRefactor). “Red”… enfin, techniquement, ci-dessous c’est Orange, car Inconclusive.

5. Comme c’est en “Red”, le développeur doit coder le code Business (ou bien le connecter ou bien injecter des objets existants) afin de le faire passer au Green. Pour cela, il suffit de copier / coller le code en bleu ci-dessous généré par TeamSpec (il y a probablement un autre moyen).

On colle cela dans un autre fichier; bon, pour faire passer au Green, j’ai mis partout des Assert True à titre d’exemple.

Lorsque tout est Green, on connecte le tout à la TeamBuild TFS afin d’être certain qu’il n’y ait pas de régression à chaque Check-in (si Gated Check in), ou bien tous les soirs.

Ensuite, on “Refactor” la partie Business, voir ses TU afin de faire plus propre. Puis, le CDP réitère en rajoutant des nouvelles “Definition Of Done”, donc cas recasse et nous voila reparti pour le cycle Red Green Refactor.

Pour aller plus loin dans les tests : Utiliser SpecFlow avec Coded-UI de VS2010 :
https://github.com/techtalk/SpecFlow/wiki/Using-SpecFlow-with-CodedUI-API

PS: Suite à l’installation de SpecFlow, ne comptez pas sur l’aide fournie pour vous donner un coup de main, mais votre moteur de recherche préféré (car l’aide PDF est en mode Brouillon et pas complet) ==> Il faut rajouter au crproj de test une référence vers l’assembly SpecFlow et un fichier App.Config contenant les informations suivantes (MsTest, mais vous pouvez choisir les autres types).