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

Dans ces mêmes commentaires, Louis Pellerin ajoutait :

De mon expérience avec GreenPepper pour le produit Talia que nous développons (un produit sans réelle interface utilisateur), nous avions une proportion d’environ 80 spécifications exécutables (GreenPepper) pour plus de 200 tests unitaires et intégrés (mstest).

Il y a aussi le billet Pendant ce temps-là, à Boulogne., d’Emmanuel Gaillot, qui donne les chiffres suivants :

L’équipe compte actuellement 6 programmeurs (dont le responsable produit), 2 graphistes, 3 modérateurs et une poignée de stake-holders. Tout ce monde travaille dans un ancien atelier réhabilité à Boulogne, dans une même pièce. L’application web est développée en TDD (à l’exception des vues). Elle est actuellement couverte par 951 assertions, réparties sur 563 tests automatisés qui s’exécutent en 35 secondes environ.

En 4 mois de boulot, nous avons consommé 150 pages de flipchart, 15 marqueurs, 100 fiches cartonnées, 2000 post-its de couleurs et tailles variées, 10 stylos feutre, 5 stylos bic, 2 bloc-notes, 50 feuilles A4, un playmobil et 300 viennoiseries.

Si vous connaissez d’autres billets ou articles du même style je suis preneur.

En attendant voici quelques informations du même type sur l’un de nos projets : 38 sprints de développement (durée 3 semaines), une équipe de développement de (en moyenne) 4 développeurs et 1 chimiste testeur/représentant des utilisateurs (plus 1 ScrumMaster, et 1 Product Owner).

L’équipe a réalisé un total de 837 tests :

• 469 tests unitaires 

• 235 tests d’intégration

• 132 tests fonctionnels (81 manuels et 51 automatiques)

ce qui représente 84% de tests (unitaires + intégration) et 16% de tests fonctionnels, mais encore 90% de tests automatiques. Les tests fonctionnels manuels coûtent seulement 2-3 heures de validation à l’équipe, qui peut donc les jouer plusieurs fois par sprint si besoin.

Tous ces tests sont le résultat d’un effort permanent de toute l’équipe : TDD, automatisation des tests fonctionnels, « refactoring » permanent des tests fonctionnels.

Les tests unitaires et d’intégration représentent environ 3000 assertions. Ils sont exécutés avec DUnit.

Voici un graphique montrant l’évolution de la répartition des tests au fil du temps, sur les sprints les plus récents :

Voici la légende et la répartition finale (où j’ai regroupé tests fonctionnels automatiques et manuels en une seule catégorie).

Cette répartition paraît assez satisfaisante : on a bien une pyramide de tests, il y plus de tests unitaires que de tests d’intégration, et plus de tests d’intégration que de tests fonctionnels. D’autre part le nombre de tests fonctionnels manuels est resté sous contrôle, et c’était l’un des objectifs de l’équipe de pouvoir exécuter tous leurs tests manuels en moins d’une demi-journée ; le graphique montre d’ailleurs qu’en cours de route, certains tests manuels ont été remplacés par des tests automatiques, afin de ne pas se laisser déborder par les tests manuels.

C’est un projet qui compte environ 180.000 lignes de code Delphi. C’est un projet de taille moyenne pour nous, nous avons des projets beaucoup plus petits, et de plus rares projets 5 ou 6 fois plus gros.

Sur ce projet, comme sur un projet précédent d’ailleurs, nous avions décidé de maîtriser la complexité cyclomatique (nous étions motivés par la constatation sur d’anciens projets que des méthodes de complexité 50 voire 70 étaient de véritables nids à bugs critiques). Le graphique ci-dessous montre sur les sprints les plus récents l’évolution du nombre total de méthodes (en bleu), et l’évolution du nombre total de méthodes dont la complexité cyclomatique est supérieure à 7 (notre limite). Sur ce projet, nous avons donc programmé plus de 6200 méthodes de complexité inférieure à 7. Toutefois nous tolérons l’existence de quelques dizaines de méthodes complexes car le bénéfice de baisser leur complexité ne nous semble pas assez important. Mais ces méthodes complexes ne représentent que 0.6% du nombre de total de méthodes !

La définition de la limite acceptable (7 dans notre cas) peut donner lieu à bien des débats, et vous trouverez fréquemment des recommandations comme 15 ou 25. Mais à mon avis, même une limite de 7 vous donne bien des opportunités de coder des bugs, car cela vous laisse libre de coder suffisamment de if, while, for et conditions booléennes tous ensemble. Donc pour moi il est important de s’imposer une limite assez basse pour vraiment tirer parti de la réduction de la complexité.

Ces données illustrent deux axes sur lesquels nous nous sommes bien améliorés ces dernières années : maîtrise des tests, maîtrise de la complexité du code. Et qu’en est-il de la satisfaction des clients sur ce projet ? Eh bien c’est assez embarrassant, je ne sais pas encore quelle est la réponse ! En effet, en nous améliorant, nous avons essentiellement déplacé le goulet d’étranglement dans d’autres secteurs de l’entreprise qui actuellement peinent à absorber notre production, et à livrer leur part du travail (pourtant ils ont vu passer plus de 30 livraisons qui fonctionnaient, ils n’auraient pas dû être surpris, non ?).

Après tout, rien de très surprenant, c’est en gros ce que prédit la théorie des contraintes.  Mais cela indique que dans de futurs projets, tout en continuant à nous améliorer sur d’autres axes (comme travailler avec des exemples et pratiquer le BDD), il va falloir travailler à introduire de l’agilité dans tous les secteurs qui contribuent à la livraison d’un produit chez des clients ! Nous atteignons peut-être les limites de ce que nous pouvons faire avec des améliorations locales.

Merci à mes collègues Sandrine et Jean pour leur aide dans la collecte des données.

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

Par conséquent les participants des dojos sont tous d’accord sur le fait qu’il faut bien nommer les tests. Rien de très surprenant, me direz-vous, c’est une bonne pratique bien connue. Par exemple dans Clean Code, le livre de l’oncle Bob dont j’ai parlé dans un billet précédent, il y a plusieurs points qui parlent du nommage correct. Le deuxième chapitre, écrit par Tim Ottinger, est même entièrement consacré à la question du nommage. Plus loin dans le livre, le chapitre « Tests propres » mentionne notamment :

Qu’est-ce qui rend un test propre ? Trois choses. Lisibilité, lisibilité et lisibilité. La lisibilité est même peut-être plus importante dans les tests unitaires que dans le code de production. Qu’est-ce qui rend les tests lisibles ? La même chose qui rend tout code lisible : clarté, simplicité et densité d’expression. Dans un test vous voulez dire beaucoup avec aussi peu d’expressions que possible. […]

La lisibilité du nom du test est donc importante pour avoir un test « propre ». Enfin dans le chapitre « Odeurs et heuristiques », il y a plusieurs points sur les noms, comme :

N1 : choisissez des noms descriptifs

N’allez pas trop vite pour choisir un nom. Assurez-vous que le nom est descriptif. Rappelez-vous que les significations tendent à dériver au fur et à mesure que le logiciel évolue, donc ré-évaluez fréquemment les noms que vous choisissez.

Ce n’est pas simplement une recommandation pour faire joli. Dans le logiciel les noms constituent 90% de ce qui rend le code lisible. Vous devez prendre le temps de les choisir soigneusement and de les garder pertinents. Les noms sont trop importants pour être traités à la légère.

[…]

N4 : des noms non-ambigus

Choisissez des noms qui rendent non-ambigus le fonctionnement d’une fonction ou d’une variable. […]

Pour l’instant je n’ai pas prêté suffisamment attention à cette question des noms des tests. J’utilisais le premier nom qui me venait à l’esprit. Suite à la « découverte » de cette bonne pratique grâce aux dojos, j’ai donc revisité mon tutoriel sur le développement dirigé par les tests (TDD), et essayé d’améliorer les noms des tests. Le tableau ci-dessous présente les noms de tests du tutoriel, ainsi que le nouveau nom que je leur ai trouvé, parfois avec difficulté.

Pour ce tableau j’ai suivi la convention utilisée par mes collègues, à savoir des groupes de mots séparés par des caractères « souligné », comme dans LeNombreDeSolutionsCalculees_DoitEtreEgal_AuNombreDeSolutionsTheoriques. Mes collègues ne trouvent pas très lisibles d’autres conventions comme tout séparer par des « souligné », comme dans le_nombre_de_solution_calculees_doit_etre_egal_au_nombre_de_solution_theoriques, ou comme tout regrouper et « séparer » par des majuscules, comme dans LeNombreDeSolutionsCalculeesDoitEtreEgalAuNombreDeSolutionsTheoriques.

En ce qui me concerne j’ai une préférence pour le_nombre_de_solution_calculees_doit_etre_egal_au_nombre_de_solution_theoriques, tout simplement parce qu’il est facile d’automatiser l’obtention d’un tel nom : il suffit d’écrire une phrase en français, et une simple macro permet d’obtenir un nom satisfaisant pour un compilateur (voir par exemple Macro to aid BDD test naming style). La troisième convention est également automatisable, mais moins lisible à mon goût.

Pour mieux comprendre les noms ci-dessous, il faut savoir que les 12 pentaminos sont représentés chacun par une lettre qui correspond à sa forme : X, L, V, I etc.

Obtenir de bons noms a été finalement assez difficile, et consommateur de temps. D’ailleurs je ne suis pas forcément satisfait de tous. Il est probable que travailler en binôme sur la question permettrait d’arriver à de meilleurs résultats.

J’ai constaté aussi que la difficulté de trouver certains noms pouvait indiquer une « mauvaise odeur ». Par exemple pour ApresAjoutDeV_EnPosition1_LesLibertesDePlace_DoiventEtreJustes_EnDiversEndroits, la longueur et le caractère vague  du nom m’indiquent que le test fait sans doute trop de choses, et qu’il vaudrait mieux le couper en plusieurs petits tests.

Travailler sur les noms a été également révélateur de défauts potentiels de structuration de mes tests. Ainsi l’une des classes comporte quatre méthodes dont les noms sont construits de manière similaire : PourUnPlateauVide_LePentaminoP_PeutEtreAjoute_EnPosition62, PourUnPlateauVide_LaProchainePositionLibre_DoitEtre1, PourUnPlateauVide_LaPosition1_DoitEtreLibre, PourUnPlateauVide_AucuneSolution_NeDoitEtreTrouvee, alors que les autres noms sont bien différents. Cela indique que ces quatre méthodes devraient certainement aller sur une autre classe de tests, ce qui permettrait de factoriser le contexte « Pour un plateau vide ». Les noms pourraient alors être simplifiés, ce qui augmenterait la lisibilité.

En conclusion, appliquer cette bonne pratique a été un exercice utile pour améliorer mon tutoriel dans une future version, et c’est une pratique que je m’efforcerai d’appliquer au quotidien.

L’article est illustré par des exemples en C#, exemples souvent tirés de cas réels dans des applications scientifiques.

N’hésitez pas à utiliser ce billet pour poster des commentaires sur l’article.