Blog Arolla

Bonnes pratiques de dév, Evénements, Programmation

TDD en pratique au Software Craftsmanship de Paris

by  • 

Jeudi 24 mai, il est 20 heures, une trentaine de passionnés du développement, des craftsmen et des aspirants craftsmen, des maîtres du TDD et ceux qui souhaitent s’y essayer se retrouvent près de Bastille. La soirée va bientôt commencer, les participants ont pris des forces grâce au buffet bien garni offert par Arolla, sponsor de la soirée. La vedette de la soirée n’est autre que le “TDD en pratique”, et Cyrille (@cyriux) en maître de cérémonie fera tout pour faire briller les yeux des passionnés.

La soirée va bientôt commencer. Tout le monde prend place. Cyrille présente la Communauté Software Craftsmanship de Paris, le thème et le déroulement de la soirée. Nous commençons par deux lightning talks : le premier sur Fest Assert, une librairie Java qui permet d’écrire des assertions ‘fluent’ par Joël Costigliola et le second sur les “quatre éléments d’un design simple” par Cyrille.

Fest assert

Joel Costigliola, contributeur au projet, nous présente cette librairie dont le but est de renforcer la lisibilité de vos tests unitaires. L’outil s’intègre avec les deux frameworks de test unitaire, JUnit et TestNG. Voyons quelques exemples pour vous donner envie d’en savoir. Pour ce faire commençons par créer une petite classe qui nous servira dans les illustrations :

package org.craft.tdd.fest;

public class Person {
	private int age;
	private String name;

	public Person(String name, int age) {
		this.name = name;
		this.age = age;
	}

	public String name() {
		return name;
	}

	public int age() {
		return age;
	}
}

Ajoutez Fest Assert aux dépendances de votre projet et ajoutez l’import static suivant dans votre classe de test et vous êtes prêt pour démarrer :

import static org.fest.assertions.api.Assertions.*;

Voici des tests simples sur les propriétés de notre classe. Jugez vous-mêmes de leur expressivité :

Person craftsman = new Person("John Doe", 22);
Person craftswoman = new Person("Jane Doe", 20);

assertThat(craftsman.name()).isEqualTo("John Doe");
assertThat(craftsman.name()).isNotEqualTo("Jackson Doe");
assertThat(craftsman.age()).as("The craftsman should be major.").isGreaterThan(18);

L’API de fest assert permet le chaînage. Cela donne par exemple :

assertThat(craftsman.name()).isEqualTo("John Doe")
				 .isNotEqualTo("Jackson Doe")
				 .contains("John")
				 .containsIgnoringCase("DOE")
				 .hasSize(8);

Vous avez besoin de tester si une valeur est ou n’est pas dans une liste Fest a une API pour cela. Notez en passant l’utilisation de la méthode utilitaire pour la création d’une liste :

import static org.fest.assertions.api.Assertions.*;
import static org.fest.util.Collections.list;
...
List<String> names = list("Linus Torvalds", "Martin Odersky", "Martin Fowler", "John
Doe");

assertThat(craftsman.name()).isIn(names);
assertThat(craftsman.name()).isNotIn("Otis Redding", "Sam Cook", "Ray Charles");

Enfin voici pour finir quelques tests sur les collections :

import static org.fest.assertions.api.Assertions.*;
import static org.fest.util.Collections.list;
...
List<String> names = list("Linus Torvalds", "Martin Odersky", "Martin Fowler", "John Doe");
List<String> names2 = list("Linus Torvalds", "Martin Odersky", "Martin Fowler", "John Doe");
List<String> names3 = list("Linus Torvalds", "Martin Odersky", "Rob Pike", "Dennis Ritchie");

assertThat(names).hasSize(4)
		 .contains("Martin Odersky")
		 .doesNotHaveDuplicates()
		 .isNotEmpty()
		 .isEqualTo(names2)
		 .isNotEqualTo(names3);

J’espère que cela vous a donné envie d’essayer Fest Assert dans votre projet !

Les quatre éléments d’un design simple

Le deuxième lightning talk parlait de design : il résumait un design simple en quatre éléments, du plus important au moins important :

  1. Il passe ses tests
  2. Il minimise la duplication
  3. Il maximise la clarté
  4. Il a peu d’éléments (it has fewer elements)

Comme le faisait remarquer Cyrille, malgré son apparente simplicité, cette liste est puissante. Pour vous en convaincre lisez l'article dont sont issus les quatre éléments. J’ai notamment aimé la démarche de l’auteur pour refactorer son code !

TDD en pratique

Les lightning talks n’étaient qu’une mise en bouche. Le vrai sujet de la soirée était le TDD en pratique. Après les lightning talks, les craftsmen et craftswomen se mettent en binôme pour travailler sur le kata ayant recueilli le plus de votes, un grand classique : Le Kata "Roman Numerals". L’exercice va se dérouler en trois sessions d’une durée de 30 min environ. A la fin de chaque session, chacun change de binôme et recommence l’exercice. Cyrille et Houssam (@houssamfakih) jouent le rôle de facilitateurs.

Lors de la dernière session de 30 minutes Cyrille et son binôme @piwai ont projeté ce qu’ils faisaient sur l’écran. Cela a permis aux autres développeurs d'observer le kata et d’échanger. C’était assez intéressant de voir comment le code évoluait. A certains moments on voyait visuellement des répétitions dans le code et évidemment le refactoring suivait.

Personnellement j’ai beaucoup aimé regarder les autres travailler. Cela me pousse à réfléchir sur ma propre façon d’aborder les problèmes. J’ai aussi constaté qu’il est parfois difficile de résister à la tentation de spéculer, d’aller trop vite et de laisser les tests “driver” le développement en suivant les étapes suivantes [Kent Beck] :

  1. Ajouter un test
  2. Exécuter les tests (les tests qu’on vient d’écrire pourrait échouer)
  3. Ne faire que le changement minimum nécessaire pour faire passer le test
  4. Exécuter les tests (les tests devraient réussir)
  5. Refactorer le code pour supprimer les duplications

Il est essentiel de résister à l'envie d'aller trop vite et d'être trop intelligent (clever) afin de ne pas perdre les intérêts du TDD. Un autre point important abordé lors du kata était le choix du prochain test à écrire. Quel prochain test est le plus intéressant à choisir ? Sans doute celui qui va nous apprendre le plus !

Et pour la route

Cette session a été l’occasion de pratiquer le TDD, de rencontrer du beau monde, de découvrir pour certains de nouveaux outils (MoreUnit, Fest Assert, MouseFeed, Infinitest). Une soirée bien sympathique en somme ! A bientôt, peut-être à la prochaine soirée de la Communauté Software Craftsmanship de Paris.

 
 
 

Quelques liens pour en savoir plus:

https://fr.wikipedia.org/wiki/Software_craftsmanship

http://manifesto.softwarecraftsmanship.org/

http://www.meetup.com/fr/paris-software-craftsmanship/

http://www.amazon.com/Software-Craftsmanship-The-New-Imperative/dp/0201733862

admin
Plus de publications

4 comments for “TDD en pratique au Software Craftsmanship de Paris”

  1. ugo bourdon
    29 mai 2012 at 15 h 26 min

    je dirais que le critère pour choisir le prochain test est le plus petit incrément fonctionnel possible, pour toujours ecrire un test qui fail mais avec un pas assez petit pour minimiser l’effet tunnel au maximum

  2. Pingback: Discussion avec Nouhoum Traoré | Arolla
  3. Joel Costigliola
    31 mai 2012 at 13 h 43 min

    Hello,

    Pour ceux qui ont essayé Fest Assert et qui trouvent ça sympathique, j’ai écris un guide qui permet de migrer facilement des assertions JUnit (assertEquals) en assertions Fest (assertThat) basé sur du find/replace avec des regexp.

    C’est ici : Convertir ses assertions JUnit en assertions Fest

    Hope it helps,

    Joel Costigliola

  4. Pingback: Les thèmes privilégiés des software craftsmen – Sondage lors la dernière rencontre du mois de mai | Blog Arolla