J’ai lu ce livre il y a un an ou deux, mais il est toujours d’actualité et je trouvais important de vous en parler. D’une certaine manière c’est toujours bon de revoir ses bases de temps à autre. Ce livre est en quelque sorte un « must » pour tout développeur, notamment ceux qui font du .Net. Il existe aussi une version inspirée de ce livre chez le même éditeur avec les exemples en Java intitulé « Unit Testing in Java » qui sera publié cette année.

Premièrement, pour bien situer ce livre, ce dernier se concentre surtout sur l’aspect « Test unitaire » et non le TDD (Développement piloté par les tests). Ce dernier y est mentionné un peu, mais l’accent de ce livre n’est pas tout simplement pas sur cet aspect.

L’auteur, Roy Osherove,  nous fait découvrir de manière pédagogique plusieurs notions essentielles lorsque l’on veut progresser dans les tests unitaires, notamment vers des cas plus complexes. Et ce, dans l’environnement de développement .Net, malgré que la plupart des notions peuvent être adaptées pour un autre environnement de développement orienté-objet.

Le TDD avec des cas simples c’est bien beau et facile, mais cela peut se corser assez vite merci. On y voit alors dans ce livre plusieurs trucs, notions et techniques tels que:

• Les techniques de base
  • Les Stubs
  • Les Mocks
  • Les différents frameworks d’isolation

• Le code de test
  • L’organisation et la hiérarchie des tests…
  • Les bonnes pratiques pour les tests

• Processus et conception
  • Intégrer les tests dans l’organisation
  • Travailler avec du « Legacy Code »

J’aime le fait que l’auteur dans les premiers chapitres s’occupe de bien définir les termes essentiels qui seront utilisés tout au long du livre tel que:

• Test Unitaire
• Test d’intégration
• State-based testing / vérification d’état
• Interaction testing / vérification de l’interaction avec d’autres objets
• Système sous test
• La régression
• C’est quoi du « Legacy Code » ? (en fait c’est du code sans tests unitaires)
• Refactoring
• Seams
• Fake
• Dynamic Fake

Point que je trouve important et qui est aussi abordé dans ce livre, c’est comment nommer nos méthodes de tests. J’aime bien la formule que l’auteur suggère, soit de nommer en trois parties séparées par le caractère « _ »:

• Nom de la Méthode
• État du test
• Comportement prévu

Ex.: IsValidFileName_ValideFile_ReturnsTrue()

Si vous avez beaucoup de tests dans votre projet, vous allez voir que ce type de nommage aidera le classement et permettra de facilement déduire le test d’après son nom.

Le Pattern AAA est aussi abordé dans le livrer et c’est un de mes préférés. Donc, je vais vous en parler un peu. Il s’agit en fait de faire notre méthode de test en trois « sections » fonctionnelles qui sont les suivantes:

1. Arrange: On prépare les variables nécessaires et autres préalables.
2. Act: Action sur l’objet ou la méthode que l’on teste
3. Assert: On compare le résultat attendu versus celui obtenu.

Exemple:

[Test]
 public void CalculateSalesBonus_VendorWithSalesBonus_BonusMade()
 {
 // Arrange
 int salesNovember = 10000;
 var calculator = new BonusCalculator();

 // Act
 var result = calculator.CheckBonus(salesNovember);

 //Assert
 result.ShouldEqual(100);
 }

Un aspect important quand on établit notre code de test, c’est de commencer par l’assertion (et oui, on commence par la fin !). Cela rend plus clair par la suite la réalisation des étapes d’Arrange et d’Act. Ce conseil me vient de JR Rainsberger que j’ai eu l’occasion de rencontrer au Code Retreat à Québec en 2011.

Personnellement, je trouve que faire des mocks peut parfois être utile, mais il faut faire attention car cela peut nous amener à faire beaucoup de code. J’aime bien dans ces cas appliquer la règle de Pareto, ou celle du 80/20, c’est-à-dire qu’on ne fera pas du code 80% plus gros pour tester un 20% de notre application. Il faut y aller alors de manière pragmatique.

L’auteur parle aussi au chapitre 8 des manières d’introduire les tests unitaires automatisés dans une organisation, encore là, une bonne section du livre. Le facteur humain n’est pas à négliger ici, car le TDD et les tests unitaires, qui introduisent une nouvelle manière de concevoir notre code, peuvent provoquer des bouleversements au passage.

Bref, si vous faites du développement avec .Net ou Java, et que particulièrement vous trouvez que c’est dur de faire des tests unitaires (et vous avez raison, car ce n’est pas une mince tâche), ce livre peut vous aider.

J’ai fait un résumé des idées de ce livre (avec une certaine adaptation) dans le mind map suivant (cliquer pour l’agrandir) :

Mes points clefs:

• C’est important de bien connaître les techniques de base (stub, mock et framework) afin de progresser dans la programmation des tests unitaires
• Organiser les tests (nomenclature, projets), n’est pas à négliger pour établir un standard dans l’équipe de programmeurs
• Pour implanter le TDD et les tests unitaires dans une organisation, il faut être prêt. Ex.: répondre aux questions, identifier les champions, gérer avec les « bloqueurs, avoir des buts spécifiques, etc.

Références:

• Livre « The art of unit Testing » sur Amazon.ca (lien commandité)
• Blogue de l’auteur Roy Osherove
• Blogue de  J. B. Rainsberger
• Article « Mocks Aren’t Stubs » (À lire !)
• Quelques définitions :
  • Mock (programmation orientée objet) 
  • Legacy code 
  • Arrange-Act-Assert