En fonction du langage de programmation:

• en .NET, voir Specflow : www.specflow.org
• en Java, voir jBehave : http://jbehave.org/
• en Ruby, voir Cucumber : http://cukes.info/

Il existe aussi des outils moins dépendants d’un langage, comme

• GreenPepper : http://www.greenpeppersoftware.com/confluence/display/GPW/Home/,
• Fitnesse : http://fitnesse.org/ 

Pour prendre du recul par rapport aux outils, il faut étudier les travaux de Dan North, qui a introduit la notion de BDD vers 2003 je crois, et qui a écrit cette introduction au BDD (en anglais, mais traduite en français par Philippe Poumaroux). On peut voir le BDD comme la spécification du comportement attendu d’un logiciel.

Il est aussi très utile d’étudier le concept de Spécification par l’exemple, concept inventé par Gojko Adzic. On peut trouver une introduction ici : http://specificationbyexample.com/key_ideas.html, mais Gojko a aussi écrit un livre complet sur la question, Specification By Example.

Ces deux concepts, spécification par l’exemple et spécification du comportement attendu, permettent de comprendre l’utilité des outils mentionnés plus haut.

Je pense que dans les dojos précédents nous avons bien compris et bien pratiqué le cycle RED/GREEN/REFACTOR du TDD :

Nous voulons maintenant comprendre comment cela s’articule avec le BDD (partant du principe que nous sommes convaincus que cela vaut le coup de s’intéresser au BDD).

Je trouve que le schéma ci-dessous de Behavior Driven Development with NBehave illustre assez bien la manière de procéder, du BDD vers le TDD :

Voici comment je comprends ce schéma :

• On se laisse donc guider par une user story (ce qui évite un risque du TDD qui est de s’égarer sur des questions peu pertinentes pour l’utilisateur final, étant donné que l’on travaille très près du code).
• La première étape est d’avoir des scénarios « Pending » – en Cucumber cela correspond au premier fragment de pont que Cucumber génère automatiquement.
• En implémentant ces scénarios, on définit itérativement l’API des classes métier. Pour cela on suit un cycle RED/GREEN/REFACTOR au niveau de l’outil de BDD, et on ne cherche pas nécessairement à implémenter le comportement réel et final : on peut utiliser des comportements « codés en dur », ou simplistes – c’est ce qu’illustrait le dojo précédent finalement. C’est la partie « Stubbed Scenario » ci-dessus.
• Une fois que l’API est stable, on implémente le comportement réel, et pour cela on pratique le RED/GREEN/REFACTOR en changeant d’outil : cette fois on fait du TDD avec un outil du type xUnit.
• Et l’on obtient un test d’acceptance (sous forme de scénario exécutable) à la fin du processus.

Aujourd’hui dans le dojo nous avons travaillé essentiellement au niveau « Real Behavior », l’API de notre classe CalibrationCurve avait en effet été stabilisée grâce au travail de la dernière fois, nous n’avons pas eu à la retoucher. Par contre nous avons complètement reprogrammé son comportement interne.

Pour commencer à programmer, nous nous sommes appuyés sur le test unitaire suivant :

class LinearRegressionTest ? Test::Unit::TestCase

  def setup
    @curve = CalibrationCurve.new
    @curve.ajoute_points(0, 10)
    @curve.ajoute_points(10, 100)
  end

  def test_calcul_slope
    assert_in_delta(0.111, @curve.calcule_slope, 0.001)
  end

  def test_calcule_ordinate
    assert_in_delta(-1.111, @curve.calcule_ordinate, 0.001)
  end

end

(désolé, pour d’obscures raisons le moteur de blog ne me laisse pas insérer le caractère « inférieur », et j’ai mis ≤ à la place dans les morceaux de code qui en avaient besoin)

On peut noter que nous n’avons pas inventé de nouvelles données du test, nous avons simplement utilisé les données déjà présentes dans le scénario qui échouait à la fin de la dernière séance :

Avec le recul, on peut se demander si ce test unitaire n’est pas complètement redondant avec le scénario, et s’il présente vraiment de l’intérêt ! En effet nous exerçons l’API de notre classe exactement comme dans le pont entre le scénario et la classe CalibrationCurve.

Par contre, en programmant les calculs nous avons identifié un cas limite (un seul point fourni par l’utilisateur) et nous avons dû prendre une décision sur le comportement attendu. Voici un test unitaire qui couvre ce cas :

class LinearRegressionTestLimite ? Test::Unit::TestCase

  def setu<
    @curve = CalibrationCurve.new
    @curve.ajoute_points(0, 0)
  end

  def test_slope_should_be_zero
    assert_equal(@curve.calcule_slope, 0)
  end

  def test_ordinate_should_be_zero
      assert_equal(@curve.calcule_ordinate, 0)
    end

end

On peut alors se demander si cette information doit rester « cachée » dans un test unitaire, ou bien s’il faut la faire remonter à l’utilisateur, via un complément de scénario. La décision dépend surement d’un dialogue avec les utilisateurs : est-ce que ce cas limite est pertinent pour eux ou non ? est-ce qu’ils sont intéressés par spécifier le comportement attendu ?

En tout cas ce petit exemple nous indique déjà que le schéma ci-dessus Story ==> Acceptance Test n’est pas si linéaire que cela : en travaillant en TDD, nous pouvons découvrir des compléments de scénarios !

Sur un point plus technique, nous avons également éprouvé le besoin d’un test unitaire pour nous assurer du bon fonctionnement de notre extension du module Enumerable, auquel nous avons ajouté une méthode mean comme ci-dessous :

module Enumerable
  def mean
    sum = self.inject(0.0) do |sum, xi|
      sum = sum + xi
    end
    return sum / self.size
  end  
end

Comme nous ne connaissions pas suffisamment le principe du inject, le test unitaire nous a rassuré sur le bon fonctionnement de notre extension mean :

class EnumerableTest ? Test::Unit::TestCase

  def setup
    @array = [10, 100]
  end

  def test_mean
    assert_equal(55, @array.mean)
  end  
end

En ce qui me concerne, je garderais comme test unitaire uniquement ce dernier point très technique, et je me contenterais du scénario et d’un complément de scénario pour le cas limite. Et vous, comment feriez-vous ?

Pour finir, le code de CalibrationCurve qui passe avec succès nos scénarios et tests unitaires :

class CalibrationCurve

  def initialize
    @x = []
    @y = []
  end

  def compute
    xbar = @x.mean   
    ybar = @y.mean
    sx2= @x.map{|xi| (xi-xbar)**2}.mean

    sum = 0
    @x.each_with_index do |xi, i|
      sum = sum + (@x[i]-xbar)*(@y[i]-ybar)
    end
    sxy = sum / @x.size

    if sx2.abs != 0 then
      @a = sxy / sx2
      @b = ybar - @a*xbar
    else
      @a = 0
      @b = 0
    end
  end

  def ajoute_points (area,concentration)
    @x.push(concentration)
    @y.push(area)

    compute
  end

  def calcul_concentration(area)
    return (area - @b) / @a
  end

  def calcule_slope
    return @a
  end

  def calcule_ordinate
    return @b
  end

end

Le but du dojo est de faire exécuter un scénario réaliste comme celui-ci dessous, que j’avais mis au point avec une collègue chimiste :

Ce qui nous intéresse c’est qu’il faut implémenter un calcul de régression linéaire,  et pour cela il sera probablement nécessaire de pratiquer un peu de TDD en plus du BDD ci-dessus, et c’est pourquoi l’exemple peut nous montrer comment s’articulent BDD et TDD.

Dans la séance du 5 janvier j’avais proposé un scénario simplifié, afin de prendre en main l’environnement de développement (j’utilise RubyMine, mais on peut aussi travailler directement en ligne de commande avec Cucumber).

L’idée était d’aligner tous les points sur une droite passant par zéro, comme cela on pouvait trouver l’équation de la droite sans la régression linéaire (dans un premier temps), et donc juste se familiariser avec l’IDE et les diverses notions (les scénarios, le pont, le code métier).

J’avais aussi un deuxième scénario pour vérifier qu’on savait bien faire des vérifications sur les nombres flottants :

Pas très excitant, mais important en calcul scientifique !

Et le troisième scénario proposait une droite qui ne passait plus par zéro :

Et justement le dojo s’était arrêté sur l’échec de ce dernier test – notre calcul de l’équation était vraiment trop simpliste :

D’après la rétrospective de la session, ces scénarios simplifiés n’étaient pas forcément une bonne idée, car ils nous ont un peu éloigné de l’objectif d’aller vers du TDD. Il n’est pas simple dans l’animation des dojos de trouver le bon équilibre entre pédagogie et bonne progression !

Ils nous ont tout de même permis de mettre au point le pont suivant vers le code métier, pont qui sera utilisé tel quel dans la session de demain :

Given /^the calibration mode is R=f\(Q\)$/ do
   #nothing
end

Given /^a calibration curve for component CO2 with the points:$/ do |table|
  @curve = CalibrationCurve.new  
  table.hashes.each do |hash|
    area = hash["Area"]
    concentration=hash["Concentration"]
    @curve.ajoute_points(area.to_f, concentration.to_f)
  end
end

Then /^the computed concentration for area (.*) should be (.*)$/ do |area, expected_concentration|
  calcul_concentration = @curve.calcul_concentration(area.to_f)
  calcul_concentration.should be_close(expected_concentration.to_f, 0.001)
end

When /^the slope should be (.*)$/ do |expected_slope|
  @curve.calcule_slope.should == expected_slope.to_f

end

When /^the ordinate at origin should be (.*)$/ do |expected_ordinate|
  @curve.calcule_ordinate.should == expected_ordinate.to_f
end

When /^the following table should be valid:$/ do |table|
    table.hashes.each do |hash|
    area = hash["Area"]
    concentration=hash["Concentration"]
    @curve.calcul_concentration(area.to_f).should == concentration.to_f
  end
end

Alors à demain à l’ENSIMAG salle 206 de 12 à 14h pour la suite !

Par conséquent, il me semble que travailler sur un tel logiciel est intéressant pour apprendre le BDD, car justement nous aimerions éviter de « polluer » les scénarios par des concepts purement techniques comme des questions de base de données. Le challenge est donc de parvenir à exprimer les scénarios avec des mots d’utilisateur et pas du jargon informatique.

Dans ce billet je vais détailler mon point de départ et illustrer les premières leçons que j’ai tirées des discussions. Bien sûr cela reste un exemple « jouet » mais je parviendrai peut-être à en faire une application complète dans quelque temps.

Je suis également passé à la rédaction de scénarios en français, ce qui est possible en Cucumber (tapez la commande cucumber -i18n fr pour avoir les équivalences).

Mon point de départ était la fonctionnalité suivante :

Les discussions ont fait apparaître que « qui veut perdre du poids » n’avait aucune influence pour le moment (je voulais souligner que cela pourrait avoir de l’importance dans de futures fonctionnalités, mais cette information superflue ici rend simplement plus difficile la compréhension de la fonctionnalité). Donc une leçon à retenir : ne pas « sur-spécifier » !

J’ai ensuite écrit de très petits scénarios comme :

ce qui m’a permit ensuite d’écrire un scénario couvrant une journée complète (les lignes commençant par # sont des commentaires) :

et ainsi de suite. Cela m’a permis d’arriver un scénario vérifiant la fonctionnalité « connaître le nombre total de calories pour la journée ».

Les petits scénarios m’ont été utiles pour mettre au point le code derrière tout cela en faisant de petits pas (tout comme quand on pratique le TDD). Mais ils contribuent à l’impression de « verbosité excessive » que mes scénarios ont donné durant la présentation, donc il faut surement accepter de les supprimer une fois que leur intention a été capturée par ailleurs dans le scénario final.

J’ai ensuite travaillé sur une deuxième fonctionnalité :

Fonctionnalité que j’ai souhaité vérifier de la manière suivante :

Un point qui a posé problème est que je ne vérifie pas la totalité du contenu de la table des aliments – cela ne me paraît pas nécessaire. Mais mes attentes sont peu claires pour le lecteur, et pour lever l’ambiguïté il aurait sans doute suffit d’écrire « la table des aliments contient notamment: ». Il faut donc rédiger les vérifications avec beaucoup de précision et de clarté.

Un deuxième problème est que mon scénario est bien plus long que la copie d’écran ci-dessus – en effet j’avais à nouveau couvert avec mes exemples une journée complète. Ce qui est inutile vu que le calcul pour la journée était déjà couvert par la vérification de la fonctionnalité précédente ! Donc une autre leçon à retenir est de ne pas « sur-vérifier ».

La troisième fonctionnalité consistait à travailler à partir d’une table pré-remplie :

etc.

Mes scénarios ci-dessus ont suscité un vif débat, car ils semblent représenter un effort démesuré par rapport au volume de code qui est testé derrière. En effet il s’agit d’implémenter une simple règle de trois, de parcourir des listes, d’utiliser une table de hachage. Je pense que la critique était justifiée, et que mes scénarios auraient pu contenir moins d’information, mais que cela ne remet pas en cause l’intérêt du BDD et l’intérêt de travailler avec des exemples (ces derniers méritant certainement d’être réhabilités dans nos processus de développement logiciel – voir mon billet précédent).

Un autre élément de débat était de savoir comment se positionner par rapport à une éventuelle interface graphique. Etant donné la manière dont j’ai écrit et réalisé les fonctionnalités, l’application n’existe pas encore, je suis simplement en train de mettre au point une bibliothèque de classes, indépendamment de la manière dont elles seront ultérieurement présentées à un utilisateur. Cette approche était confortable par certains, mais d’autres auraient préféré travailler à partir d’une interface graphique (le risque étant de mettre au point un bon modèle métier bien testé, mais de ne pas satisfaire les utilisateurs qui veulent voir très vite une interface graphique).

Je pense que le schéma suivant de DDD Vite Fait illustre l’endroit où j’essaie de me placer pour l’instant – mes scénarios concernent le domaine, et pas l’application, ce qui est source de confusion :

Pour finir ce billet, au cas ou vous soyez curieux de ce qu’il y a derrière (c’est généralement le cas quand je présente les scénarios), je vous montre le code que j’ai écrit pour le pont entre les scénarios exécutables et les classes du domaine :

# encoding: UTF-8

require 'F:\ruby\cucumber\comptageCalories\ComptageCalories\compteur_calories.rb'
require 'F:\ruby\cucumber\comptageCalories\ComptageCalories\table_aliments.rb'

Before do
  @compteur = CompteurCalories.new
  @table_aliments = TableAliments.new
end


When /^le nombre total de calories devrait être (.*)$/ do |calories|
  #puts @compteur.total_calories
  @compteur.total_calories.should be_equal calories.to_i
end

When /^une table des aliments vide$/ do
  #rien
end

When /^la table des aliments contient:$/ do |table|
  # table is a | confiture | 1 | cuillère à café | 30 |
  table.hashes.each do |hash|
    reference = @table_aliments.reference(hash["aliment"])
    reference.quantite.should == hash["quantite"]
    reference.unite.should == hash["unite"]
    reference.calories.should == hash["calories"]
  end
end

When /^je mange (\d+\.?\d*) (.*) (de\s+|d')(.*\w|.*%) \((\d+) (.*) valant (.*) calories\)$/ do  |quantite_dans_unite,unite1, de, nom_aliment,reference_dans_unite,unite2,reference_en_calories|
  @table_aliments.ajoute(nom_aliment, reference_dans_unite,unite2, reference_en_calories)
  @compteur.ajoute(nom_aliment,quantite_dans_unite, reference_dans_unite, reference_en_calories)
end

When /^je mange (\d+\.?\d*) (.*) (de\s+|d')(.*\w|.*%)$/ do |quantite_dans_unite,unite1, de, nom_aliment|
     reference = @table_aliments.reference(nom_aliment)                   
     reference_dans_unite = reference.quantite                                
     reference_en_calories = reference.calories
     @compteur.ajoute(nom_aliment,quantite_dans_unite, reference_dans_unite, reference_en_calories)  
end


When /^la table des aliments suivante:$/ do |table|
  # table is a | confiture | 1 | cuillère à café | 30 |
  table.hashes.each do |hash|
    @table_aliments.ajoute(hash["aliment"],hash["quantite"],hash["unite"],hash["calories"])
  end
end

Les discussions ont certainement dérivé de l’objectif initial qui était d’explorer différentes manière d’écrire des spécifications exécutables, mais elles n’en ont pas moins été très intéressantes. Il y a eu trop d’échanges pour tout retracer dans un seul billet, donc ici je vais me concentrer sur l’un des aspects : pourquoi s’intéresser au BDD ?

En effet, certains participants ont pu être surpris par l’approche elle-même : en gros, pourquoi passer tant d’énergie à décrire des exemples alors que l’application pourrait très bien être décrite par des règles plus abstraites voire des formules mathématiques ? Le BDD, avec son caractère très verbeux, semble un effort inutile, et en tout cas ne paraît pas « faire gagner du temps« . Il y a eu des échanges assez vifs sur ce thème, et voici quelques éléments qui ressortent en faveur du BDD :

• le pouvoir des exemples est souvent sous-estimé. Je viens de parcourir le livre de Gojko Adzic 
  

  Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

              pour trouver des arguments complémentaires sur ce thème :

  • les exemples sont un medium de communication simple et naturel, nous les utilisons tout le temps, sans même nous en rendre compte.
  • les gens qui élaborent les règles métiers abstraites le font généralement à partir d’exemples, qui sont ensuite perdus. Les développeurs doivent souvent ré-inventer d’autres exemples pour comprendre ce qu’il faut faire, ou pour explorer les cas limites. Plus tard les testeurs vont également ré-inventer d’autres exemples. Pourquoi ne pas travailler sur des exemples explicites dès le départ, les partager et les faire vivre tout au long du projet ?
  • les exemples, tests et spécifications sont des notions fortement liées de la manière suivante :
    
    Par conséquent, les exemples devraient avoir leur place dans nos méthodes de travail.
  • en comparaisons avec les exigences ou spécifications abstraites, les exemples réalistes laissent beaucoup moins de place pour l’incompréhension.
  • les exemples réalistes nous forcent à penser plus concrètement, et nous évitent de laisser des choses de côté trop vite.
• les scénarios du BDD sont exécutables. On ne parle pas ici de tests fonctionnels sous la forme d’un document Word, mais de fichiers textes qui peuvent être joués automatiquement et  aussi souvent qu’on le souhaite (dans l’intégration continue, dans les tests exploratoires). Par conséquent cette approche favorise le feedback fréquent que l’on recherche dans une approche agile.
• les scénarios du BDD constituent des tests d’anti-régression.
• il y a des cas où le côté verbeux et détaillé est clairement un avantage, par exemple quand on travaille avec des équipes offshore avec lesquelles il est difficile de communiquer.
• une fois au point, les scénarios textuels du BDD peuvent être modifiés, complétés, enrichis directement par les gens du métier, sans avoir besoin de faire appel à un développeur (lequel reste indispensable pour écrire le « pont » initial avec le code de l’application testée).
• les scénarios du BDD sont compréhensibles par le Product Owner, et peuvent servir de preuve de la bonne réalisation de la fonctionnalité souhaitée.
• le BDD sert également à découvrir le modèle métier, à se mettre d’accord sur un langage commun. Souvent les professionnels d’un domaine utilisent des abus de langage : travailler en BDD permet de lever les ambiguïtés correspondantes. 

Pour moi, la raison initiale de mon intérêt pour le BDD est l’intérêt que d’autres professionnels y portent. Certains travaillent de plus en plus avec ces outils, et pour preuve récente on peut consulter les chiffres suivants sur ce billet de Christian Blavier :

Voici quelques métriques que je viens de réunir dans différents contextes :
- secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper
- secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d’une centaine de tests par an
- encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d’une semaine
- secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d’exp complet est disponible ici : http://usi2008.universite-du-si.com/WebcastArchi.aspx (session A10)
- secteur open source , octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home

De plus je constate que dans nos projets, l’incompréhension entre équipe et product owner reste source de gaspillages importants, et se traduit en « retravail » sur des histoires utilisateurs que tous pensaient honnêtement bien terminées. La raison : tout simplement des points qui paraissaient tellement évidents pour tous que personne n’en avait discuté les détails. Dans certains cas, se forcer à écrire des exemples du comportement attendu aurait fait dissipé instantanément l’incompréhension.

C’est pourquoi je suis motivé pour poursuivre l’exploration du BDD. Il reste bien sûr à gagner plus d’expérience pour comprendre quelle est la place de cet outil dans la réalisation d’un logiciel et comment il s’articule avec le reste (notamment avec les maquettes d’interfaces graphiques – un autre thème de discussion de la soirée), quand l’employer et quand ne pas l’employer. En tout cas le BDD apparaît comme un outil complémentaire, qui ne remplace peut-être rien d’existant, mais qui probablement peut éviter des erreurs d’incompréhension, et donc au final fera gagner du temps à l’échelle d’un projet.

GreenPepper est tellement flexible que les mots-clés Given/When/Then ne sont même pas obligatoires. Ainsi on peut écrire des scénarios comme celui-ci :

Voici le résultat de l’exécution :

Au début l’absence totale des mots-clés m’a un peu dérouté. Mais à la réflexion c’est la même logique qui me conduit à ne pas utiliser de When dans mes scénarios !

Et vous, qu’en pensez-vous ? Est-ce que ce scénario vous paraît facilement compréhensible ?

Durant le dojo il y a eu des questions sur la manière dont j’avais rédigé les spécifications en Cucumber, ce qui est normal car le format Given/When/Then offre beaucoup de flexibilité. Rien ne vous force à utiliser When par exemple, ou à limiter les tests à des sections Then. En ce qui me concerne, j’ai l’habitude quand je code de faire les calculs au moment où l’on demande les résultats (ce qui est possible quand il y a peu de données, et évite de gérer des questions de cohérence données/résultats). Donc je n’éprouve pas trop le besoin de mentionner un déclenchement avec un When par exemple. Mais c’est probablement un cas où mon style et mes habitudes de programmation influencent directement sur la rédaction des spécifications exécutables, ce qui n’est guère souhaitable – dans le BDD nous souhaitons justement éviter de polluer les spécifications par des concepts très liés à l’implémentation, pour rester focalisés sur le modèle métier.

Ces questions rejoignent mes propres interrogations, car je trouve encore difficile, face à une feuille blanche, de me lancer dans l’écriture de spécifications. Il serait de plus souhaitable, sur un exemple donné, de comparer diverses manières d’utiliser le format Given/When/Then, pour déterminer ce qui est le plus clair, pour voir ce qui permet d’arriver à une meilleure collaboration et compréhension entre plusieurs personnes, et pour voir comment s’élabore un langage commun au sujet d’une application. C’est pourquoi nous allons utiliser la prochaine réunion du CARA, ce lundi 18 janvier (de 18h45 à 21h) pour faire un atelier concret sur la question.

Si le sujet vous intéresse, venez apprendre avec nous ! Il n’y aura pas de programmation a priori, simplement du travail sur papier ou tableau. Pas de présentation théorique non plus ! Nous démarrerons la séance en montrant des exemples concrets de scénarios pour ceux qui ne sont pas familiers avec la syntaxe.

A titre d’illustration de mon propos sur Given/When/Then et l’absence de When, voici les scénarios Cucumber que nous avons utilisés le 5 janvier. Le 18 janvier j’apporterai un autre exemple sur une application plus « grand public », un logiciel de comptage de calories – sujet intéressant pour ceux qui viennent de prendre de bonnes résolutions !

J’ai suivi les instructions de cette page How to Install Cuke4Nuke :

Par contre j’avais Ruby 1.9, cela n’a pas fonctionné (étape 6, installation de cuke4nuke) :

donc il faut bien partir sur Ruby 1.8.6. Problème, la page How to Install Cuke4Nuke m’a pointé sur le téléchargement d’un installateur ruby186-26.exe, sur lequel Cuke4Nuke ne s’installe pas bien du tout, apparemment parce que RubyGems ne fonctionne pas bien dans cette version 186-26. Après une bonne heure passée à chercher des informations sur des messages cryptiques, un forum m’a fait découvrir un installeur ruby186-27_rc2.exe sur cette page. Eh bien les instructions d’installation ne fonctionnent qu’avec cette version !

Ensuite j’ai suivi les explications « How to use it » sur la page How to Install Cuke4Nuke, mais j’ai encore eu quelques ennuis d’installation. A l’exécution, cuke4nuke ne reconnaissait pas le fichier .wire qui fait le lien avec .NET, ce que j’ai fini par découvrir grâce à l’option -v (pour verbose) :

J’en ai déduit que cela indique qu’il manque ‘ »json », à installer de la manière suivante :

Et j’ai eu de la chance, car ensuite Cuke4Nuke a fonctionné comme attendu :

Bien sûr j’ai dû réaliser un pont spécifique, avec le code ci-dessous dans ma solution :

using Cuke4Nuke.Framework;
using NUnit.Framework;

namespace PenduAvecCuke
{
    public class Scenarios
    {
        private Game game;

        [Given(@"^the secret word (.*) and the remaining count (\d+)$")]
        public void InitializeGame(string secret, int remaining)
        {
            game = new Game(secret, remaining);
        }

        [Given(@"^the user has already proposed the letters (.*)$")]
        public void ProposeLetters(string letters)
        {
            foreach (char c in letters)
            {
                game.ProposedLetter = c;
            }
        }

        [When(@"^the user proposes the letter (.*)$")]
        public void ProposeLetter(char letter)
        {
            game.ProposedLetter = letter;
        }

        [Then(@"the game displays (.*) and the remaining count is (\d+)$")]
        public void DisplayResult(string display, int remaining)
        {
            Assert.That(game.DisplayedWord, Is.EqualTo(display));
            Assert.That(game.Remaining, Is.EqualTo(remaining));
        }

    }

C’est donc très similaire à la classe équivalente dans mon exemple avec NBehave.

La grande différence, si j’ai bien tout suivi, c’est que dans le cas de Cuke4Nuke, Cucumber (sous Ruby 1.8) tourne de manière cachée, vous permettant de l’utiliser sans écrire une seule ligne de Ruby. Cuke4Nuke sert en fait d’intermédiaire entre Cucumber/Ruby et la DLL .NET, en reroutant les appels de Cucumber vers la DLL.

Dans le cas de NBehave, c’est NBehave qui fait tout, et Ruby n’est pas du tout impliqué.

En conclusion, pas mal de difficultés d’installation liées à la version de Ruby, et des instructions incomplètes. C’est surement facilement surmontable pour quelqu’un qui connaît bien Ruby, mais ce n’est pas mon cas et cela m’a couté environ 4 heures de travail juste pour arriver au bout de cet exemple.

Comme j’ai passé ces derniers jours le nez collé à la fenêtre de commandes, j’ai du mal à prendre du recul, et à donner autre chose que des impressions. A première vue, je ne saisis pas trop l’intérêt de toute la machinerie Cuke4Nuke, disons par rapport à la simplicité d’une approche native comme NBehave. Si le but c’est de quand même faire du Ruby dans un contexte .NET, alors autant passer en Cucumber sous IronRuby ? En tout cas vous avez le choix, tout fonctionne.

Et sinon, si l’on veut se focaliser sur la maîtrise du BDD, ca vaut probablement le coup de travailler directement en Cucumber sous Ruby, au moins le temps de bien maîtriser les concepts.

Et vous, qu’en pensez-vous ?

Installer IronRuby

1. télécharger IronRuby depuis la page du projet. Dans mon cas j’ai pris la version 0.9.3 sur cette page. Attention, ne pas prendre le fichier .MSI, cet installateur installe obligatoirement IronRuby dans C:\Program Files, et j’ai découvert péniblement que l’installation de Cucumber ne tolère pas bien les espaces dans les noms de chemins ! Donc prenez bien le fichier .ZIP, que vous allez extraire dans par exemple C:\ironruby.
2. insérer C:\ironruby\bin dans la variable d’environnement système PATH de Windows. Cela peut être l’occasion de télécharger l’excellent utilitaire RapidEE qui offre un accès bien plus pratique à ces variables.
3. lancer une fenêtre de commande DOS (ou mieux PowerShell), taper « ir », et vérifier que l’on obtient bien le prompt IronRuby comme ci-dessous

Vous pouvez alors vérifier que vous êtes réellement dans le monde .NET. Voici par exemple le chargement puis l’utilisation de la classe Game développée à l’occasion des billets précédents :

Magique, non ? J’ai trouvé comment faire le chargement de l’assembly .NET grâce à cette vidéo Using Cucumber to test CLR assembly.

Faire tourner Cucumber sous IronRuby

Cette partie a été la plus laborieuse pour moi. Je me suis inspiré des différents articles cités en référence plus bas. Voici comment j’ai procédé.

Dans la fenêtre de commandes, taper « igem install -bindir c:\ironruby\bin cucumber rspec », cela devrait donner quelque chose comme :

à chaque fois j’ai eu des erreurs relatives à la documentation comme ci-dessus, mais elles ne paraissent pas bloquantes. Pour éviter ces erreurs et gagner du temps sur l’installation, on peut éventuellement utilise les options « –no-rdoc –no-ri » sur la ligne de commandes.

Ensuite il faut créer les fichiers icucumber.bat et icucumber comme indiqué ci-dessous (image tirée de cette page) :

On peut alors vérifier que tout cela fonctionne en tapant « icucumber -help ».

Tester le jeu

Dans un dossier pendu\features, j’ai créé trois fichiers textes :

qui contiennent mes scénarios (je n’ai pas pu garder un seul fichier comme précédemment, cela n’a pas l’air bien supporté par (i)cucumber contrairement à NBehave).

Le dossier steps_definitions contiendra le fichier pendu_steps.rb qui me servira à réaliser le pont (en Ruby) vers ma classe C#.

La première exécution de icucumber me propose un modèle pour les fragments de code qui font faire le pont, c’est l’une des caractéristiques bien sympathiques de Cucumber :

On voit que le modèle comporte des expressions régulières, il suffit de les affiner un peu,  d’appeler le code C# avec les arguments que l’on extrait des expressions régulières, et de faire les vérifications nécessaires dans les parties « Then ».

Voici le fichier pendu_steps.rb, réalisé à partir des fragments suggérés ci-dessus :

Ma principale difficulté a été d’arriver à séparer la chaîne letters en caractères individuels. En effet letters.each rend la chaîne elle-même, et curieusement, aucune erreur ne se produit quand on affecte une chaîne à game.ProposedLetter, qui est pourtant définie de la manière suivante :

private char proposedLetter;



public char ProposedLetter

{

    set

    {

        proposedLetter = value;

        ComputeResult();

    }

}

Le test ci-dessous montre que seule la première lettre de la chaîne est bien prise en compte.

Donc voilà sans doute une première subtilité de l’interopérabilité de IronRuby et de C#, probablement normale, mais qui m’a un peu dérouté.

Cette petite difficulté résolue grâce à la méthode « split », voici le résultat de l’exécution de icucumber :

Tout fonctionne bien, ca valait le coup de persévérer ! Seul l’affichage en couleur n’est pas au point, d’où l’option -no-color.

En conclusion, arriver à faire marcher cet exemple a été un peu laborieuse pour moi, surtout pour faire tourner Cucumber sous IronRuby. Toutefois IronRuby a l’air d’être un projet très actif, et s’approche d’une version officielle 1.0. Il est donc probable que les quelques difficultés rencontrées vont bientôt disparaître.

Références

- Installing Cucumber with IronRuby 0.9.2

- On running Cucumber under IronRuby 0.9, de Thomas Lundström.

- How-to: Use Cucumber with .NET and C# under IronRuby, de Rupak Ganguly.

- Cucumber and IronRuby: It Runs!

Tout d’abord les scénarios, tous écrits dans un fichier texte appelé pendu.scenario :

Story: handle one letter

Scenario: scenario1 (one wrong letter)

    Given the secret word SANGLIER and the remaining count 6
    When the user proposes the letter Z
    Then the game displays ******** and the remaing count is 5
    
Scenario: scenario2 (one good letter)

    Given the secret word SANGLIER and the remaining count 6
    When the user proposes the letter A
    Then the game displays *A****** and the remaing count is 6
    
Story: handle two successive letters

Scenario: scenario3 (a good letter followed by a good letter)
    Given the secret word SANGLIER and the remaining count 6
    Given the user has already proposed the letters A
    When the user proposes the letter S
    Then the game displays SA****** and the remaing count is 6
    
Scenario: scenario4 (a wrong letter followed by a good letter)
    Given the secret word SANGLIER and the remaining count 6
    Given the user has already proposed the letters Z
    When the user proposes the letter S
    Then the game displays S******* and the remaing count is 5    
    
Story: handle the end of the game

Scenario: scenario5 (lost game)
    Given the secret word SANGLIER and the remaining count 6
    Given the user has already proposed the letters ZZZZZZ
    Then the game displays ******** and the remaing count is 0    
    
Scenario: scenario6 (winning game)
    Given the secret word SANGLIER and the remaining count 6
    Given the user has already proposed the letters XYZSANGLIER
    Then the game displays SANGLIER and the remaing count is 3    
   

A ce stage de votre lecture, il serait intéressant de voir ce que vous pensez de cette information. En tant que développeur, avez-vous assez d’informations pour programmer un jeu qui fonctionne ? En tant que testeur, avez-vous des idées sur d’autres scénarios que vous pourriez ajouter ? Est-ce que tout le monde comprend bien de quel jeu on parle ?

Au fait, testeur, notez bien que vous n’avez pas besoin d’un autre outil que Notepad si vous voulez modifier ou compléter ces scénarios.

Maintenant, un peu de cuisine informatique, il faut bien interpréter ce fichier texte. Pour cela, dans NBehave il faut programmer une classe portant l’attribut ActionSteps, comme ci-dessous :

[ActionSteps]
public class Scenarios
{
    private Game game;

    [Given("the secret word $secret and the remaining count $remaining")]
    public void InitializeGame(string secret, int remaining)
    {
        game = new Game(secret, remaining);    
    }

    [Given("the user has already proposed the letters $letters")]
    public void ProposeLetters(string letters)
    {
        foreach (char c in letters)
        {
            game.ProposedLetter = c;
        }
    }

    [When("the user proposes the letter $letter")]
    public void ProposeLetter(char letter)
    {
        game.ProposedLetter = letter;
    }

    [Then("the game displays $display and the remaing count is $remaining")]
    public void DisplayResult(string display, int remaining)
    {
        game.DisplayedWord.ShouldEqual(display);
        game.Remaining.ShouldEqual(remaining);
    }
}

Oups, il y a un peu de duplication dans ma classe (violation du principe DRY) – il faudra factoriser le code entre ProposedLetters et ProposeLetter par exemple.

Sinon vous constatez sans doute que le principe de cette classe est facile à comprendre, et découle assez naturellement des tests. Avec NBehave, je n’ai pas vu de moyen de générer partiellement ce code comme le fait Cucumber, mais je suppose que ce sera résolu ultérieurement.

Voici la sortie de NBehave:

Cette sortie illustre le seul problème que j’ai rencontré, les titres de stories ne sont pas affichés correctement par rapport à leurs scénarios, il y a un décalage.

En conclusion, une expérience très positive, et je suis content de voir que NBehave est toujours bien vivant !