[agile conference] – Comment écrire du code testable

Sur les bancs de la faculté, j’essayais déjà d’écrire des tests unitaires tant bien que mal. Heureusement, je me suis améliorée depuis. Je me suis rendue compte au fil des années que certaines pratiques empêchaient les tests d’être posés. J’ai rencontré un framework magique qui palliait à tout cela. Au bout d’un moment, je ne distinguais plus le bien du mal.

Un jour, on m’a parlé des publications de Misko Hevery et tout a changé quand j’ai regardé ses vidéos. C’est cette expérience que je veux partager avec vous.

Il faut clairement savoir ce qui rend votre code difficilement testable pour que vous en débarrasser. Voici le plan de la session “Comment écrire du code testable” présenté à la conférence Agile France 2010 :

  1. Un constructeur cher
  2. Des instanciations directes
  3. Des blocs statiques
  4. Une dynastie de classes
  5. Des états globaux
  6. Annuaire de service
  7. Interroger des collaborateurs
  8. Des classes hyperactives
  9. Des méthodes trop chargées
  10. Mélanger les objets valeurs et les objets services

Si vous faites déjà du Test Driven Development, ne partez pas encore. Votre code est testé  mais les tests sont lents à s’exécuter, difficile à maintenir? Parfois ils passent, d’autres fois non? Vous aurez peut être des explications avec cette présentation.

What went well

  • Salle pleine (ou presque)
  • Timebox respecté
  • Quelques messages sont bien passés : la simplicité n’est pas simple, les états globaux sont le mal
  • Pas trop de stress
  • Présentation relativement vivante, vu le sujet. Bravo d’ailleurs à Julie qui a tenu une demi-heure alors qu’elle n’est pas dans notre domaine.
  • Déroulement des slides fluide comme je le souhaitais
  • Il y a eu des questions
  • Au moins quelques personnes ont aimé (pas de baillement particulier, 3 personnes ont demandé le PPT sur clef, 2 ont rempli le perfection game sans que je le demande, 9/10 c’est une très bonne note).
  • Une discussion sympa après la session avec quelqu’un qui comprenait maintenant pourquoi les singletons posaient problème. Ca fait plaisir 🙂

What went wrong

  • Présentation trop dense. Plusieurs personnes m’ont dit que la fin est allée trop vite.
  • Sur la préparation, je n’avais pas prévu assez de temps : on croise des gens qu’on connait sur le chemin donc on discute un peu, il n’y avait pas de barko, quand je suis allée en chercher un, je n’ai pas penser à demander une télécommande.
  • Il manquait un exemple sur le test à la mockiste. Une remarque à la fin (“on peut utiliser du static”) m’a fait pensé que je n’avais pas été claire sur l’impossibilité de mocker les méthodes static.
  • J’etais assise pour passer les slides de facon fluide et ne pas marquer de temps d’arrêt entre chaque clic.  Mauvais choix car moins dynamique. J’aurais pu demander une télécommande.
  • Les questions un peu longues ont été reportées à la fin et du coup je ne m’en rappelais plus d’une. La prochaine fois, je les écrirai sur un tableau au fur et à mesure. Je peux aussi reserver plus de temps pour les questions.
  • Certaines personnes copiaient le contenu des slides. Pourtant j’avais mis du contenu dessus justement pour que les gens puissent se focaliser sur l’écoute et la compréhension.
  • J’ai manqué la présentation de Régis Medina sur le Problem Driven Development (mais je crois qu’elle a été filmée) et d’Eric Mignot sur “Refactoring d’un legacy par les tests”.
  • Je viens de voir une photo que Julie a prise du fond de la salle. On ne voit pas grand chose !!!! Plutot que demander si on voyait, j’aurais du aller au fond physiquement pour m’en rendre compte.

Puzzles

  • La session était-elle vraiment pour les débutants ?… peut-être plus débutant/intermédiaire. Est-ce que les débutants ont réussi à suivre?

Lessons (re) learnt

  • La compréhension se fait mieux avec des exemples
  • … de la vie courante, ça marche bien !
  • Trop d’infos tuent l’info. La prochaine fois, je me contenterai de quelques symptômes pour mieux les expliquer. Ou prendre une session plus longue (mais cela risque de faire trop).
  • Un quart d’heure de préparation ne suffit pas
  • Des illustrations pleine page permettent un impact plus fort
  • Il faut annoncer que les slides sont disponibles dès le début pour libérer les esprits.

Merci aux organisateurs et aux personnes présentes !

Je remercie plus particulièrement Misko Hevery, qui m’a donné l’autorisation de reprendre de nombreux éléments de son guide pour la présentation.

Nombre de vue : 54

AJOUTER UN COMMENTAIRE