Étiquette : TDD

Agile Tour Québec 2012: Les sessions Partie 1

Bien que j’étais un organisateur, j’ai pu assister à plusieurs sessions lors de l’Agile Tour qui a eu lieu le 6 novembre dernier à Québec. Voici donc mes impressions sur ce que j’ai vu dans les sessions du matin (ceux de l’après-midi seront dans le billet Agile Tour 2012: Les sessions Partie 2):

Développement orienté comportement et automatisation des essais d’acceptation (BDD)

par Christian Roy et Jean-François Nadeau

Je connais bien le sujet (Behavior Driven Development ou BDD) et aussi l’outil Specflow que j’ai recommandé et appliqué sur un de mes projets. Specflow est comme une sorte de version .Net de l’outil « Cucumber » qui est utilisé pour automatiser des tests d’acception qui fonctionne avec le langage Ruby. J’étais curieux de voir comment les présentateurs avaient utilisé le tout dans leur contexte. La présentation se divisait en trois parties:

  1. Théorie
  2. Démonstration
  3. Leçons apprises

Présentation très dynamique et amusante au début pour expliquer la théorie. Cela a fait un peu contraste avec la démo, mais bon c’était très intéressant somme toute. Dans la démo, on montrait l’utilisation de Sélénium Web Driver avec Specflow. Le tout était réalisé avec le patron du « PageObject ». C’était très intéressant. Par contre, je reste avec l’impression que c’est toujours un peu lourd de tester la couche graphique, et ce peu importe l’outil. On a peu parlé du TDD et de comment il s’intègre avec le BDD. Je m’interroge toujours un peu sur cet aspect que je trouve important et négligé. Je crois que les tests unitaires ne doivent pas être ignorés même si on a des tests d’acceptation automatisés grâce au BDD. J’aimerais bien voir un bel exemple pratique de tests BDD et de tests unitaires côte à côte dans un projet. Dans les leçons apprises, on a parlé de l’outil Amnesia pour aider l’exécution de tests avec une BD. Je suis intrigué, autre chose à regarder plus tard. Et un aspect que je trouve très important, les développeurs étaient impliqués dans la création des scénarios. En bref, une bonne présentation et de bonnes discussions ont eu lieu.

Références:

Propulsez votre architecture avec les TDD et les Mocks

par Félix-Antoine Bourbonnais

Mon collègue de Agile Québec, Félix-Antoine, n’est pas seulement dynamique lors de nos rencontres, il l’est aussi comme présentateur. C’est donc avec passion qu’il nous présente les différents styles de TDD avec les termes style « Classique/Chicago » ou style « Mock/London ». Je ne connaissais pas trop cette distinction, mais elle est similaire à d’autres termes comme le « State-Based testing » ou basé sur l’état et le « Interaction-Based Testing » centré sur les interactions.

Le TDD doit se voir avant tout comme un outil de découverte et d’aide à la conception de l’architecture logicielle. Les tests qui en résultent sont un peu comme un effet secondaire. Félix-Antoine nous a partagé son expérience en nous montrons ce qui est fondamental avec les tests, soit : Tester les modules en isolation. L’utilisation des mocks est une technique qui aide à cela. Encore faut-il que notre code soit bien organisé pour en profiter sans trop de « douleur ». C’est là, que l’application de bonnes pratiques comme l’utilisation d’abstraction (c.-à-d. les interfaces) , du « Clean Code », les principes SOLID et le « Tell don’t ask » sont très importantes pour réaliser de bons tests unitaires. L’idée est de combiner ces différentes techniques selon ce que l’on veut découvrir (conception ou algorithme). Pour finir, Félix-Antoine nous recommande fortement le livre « Growing Software Oriented by Tests » qui semble s’appliquer, malgré que les exemples sont en Java, aux différents langages orientés-objet.

Références:

Publicité

Notes de Lecture: The Art of Unit Testing

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:

Est-ce que le TDD augmente la vitesse de développement ?

Bon, retour à mon blogue après quelques mois de pause. Je me suis permis aussi un petit relooking à mon blogue.

image

Bon, revenons au sujet de ce blogue:

Est-ce que le TDD (Test-Driven Development) augmente la vitesse de développement ?

D’un point de vue d’un programmeur concentré sur sa tâche, la réponse est non. Les tests sont un surplus de travail pour lui.

Par contre, si ouvre un peu plus notre horizon et si on regarde pour voir quelle est la place de la tâche de programmation dans le processus global, on retrouve une nouvelle perspective:

L’activité de développement consiste à faire tout le travail pour amener un concept ou un besoin à se transformer en valeur ou si vous préférez turning concept into cash. Cela commence avec une idée et se poursuit avec la conception, l’implémentation et la livraison.

Alors oui, le TDD augmente la vitesse de développement car il permer de:

  • Écrire le code sans bogue ou défaut de conception au premier jet
  • Répondre avec précision au besoin du client
  • Diminuer la complexité
  • Rend le code "agile" et plus facile à modifier.
  • Et bien d’autres avantages…

Scott Bellware, toujours intéressant dans ses propos, parle de tout cela dans un récent article de son blogue. Je vous invite à aller lire l’article en question:

http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html