Catégorie: Tests unitaires

J'aime bien lire des billets qui contiennent des informations factuelles sur de vrais projets, car cela permet de se situer par rapport à d'autres équipes et entreprises. Récemment j'ai vu notamment le billet Démarches de tests fonctionnels, de Christian Blavier, qui citait des chiffres intéressants (dans les commentaires du billet) :

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).

» Lire la suite!

Avant de passer au compte-rendu du dojo d'aujourd'hui, voici un nouvel éclairage sur l'articulation entre TDD et BDD, que j'emprunte à ce billet Behavior Driven Development with NBehave (trouvé grâce à cet autre billet Bien Tester une application Asp.net MVC sur le BDD par Guillaume Saint Etienne).

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 :

» Lire la suite!

Une bonne pratique qui est apparue très rapidement dans nos dojos de programmation est de bien nommer les tests. En effet, comme les dojos successifs sont séparés de plusieurs semaines, à chaque fois on redécouvre le code, et quand les tests sont mal nommés, nous sommes obligés de les relire entièrement pour les comprendre. En fait l'un des avantages des dojos est de simuler sur une courte période ce qui se passe dans la vie réelle : quand vous revenez sur votre code plusieurs mois ou années plus tard, vous avez parfois l'impression qu'il a été écrit par quelqu'un d'autre, non ?

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 :

» Lire la suite!

Quand je passe en revue les tests unitaires écrits sur nos applications, je constate une énorme proportion de tests du type "tel calcul doit donner précisément telle valeur". Ce type de test est bien sûr tout à fait nécessaire. Toutefois je constate que d'autres tests ne sont pas aussi souvent présents qu'ils pourraient l'être. Ce sont des tests qui exploitent les propriétés particulières des objets métiers, et ces tests sont très courts et très faciles à mettre en oeuvre. Il serait donc dommage de s'en priver. Mon dernier article illustre ce type de tests, dont le point commun semble être un principe de vérification d'invariances.

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.