TDD & SQL

La semaine dernière j’animais une PSD et certains participants ont profité de l’occasion pour jouer avec le kata des chiffres romains. Hasard ou rappel inconscient, c’était justement le kata de février de notre ami 12meses12katas.

Bref, j’ai joué aussi et comme l’ambiance s’y prêtait bien, j’ai ressorti ma doc de mysql. Un petit guard dans un coin pour avoir mon autotest et hop c’est parti. J’ai fait une petite vidéo du début pour vous partager de quoi ça peut avoir l’air et démystifier un peu le tdd avec le sql. Dans la session la semaine dernière nous avons pris l’option de ne pas utiliser de framework « sur étagère », histoire de bien comprendre ce qui se passe en refaisant juste ce dont nous avions besoin. C’est cette option que j’ai repris ici.

Refactoring challenge

Mercredi soir, le groupe Alt.Net de Montréal m’a invité à un coding-dojo dans les locaux de Microsoft qui leur ouvre ses locaux.

Cela a encore été une bonne occasion d’apprentissage.

• Nous avons pris le temps d’explorer plusieurs manières d’exprimer nos tests : les  assertions basiques de NUnit, l’écriture d’une contrainte personnalisée.
• Nous avons évoqué le Broken Test Pattern avant la pause. Partir avec un test rouge avant la pause nous aide au retour à savoir où nous en sommes.
• Nous avons utilisé nos moments de refactoring pour introduire au maximum le langage du domaine qui faciliterait une conversation avec un expert du domaine.
• Chemin faisant nous avons créé de la duplication algorithmique et nous avons ressenti le dilemme entre payer cette dette et augmenter les capacités de notre code.

Cela a été une séance très agréable avec beaucoup d’interactions. Cela nous a tous donner envie de refaire une séance de ce type à l’automne.

Le lendemain matin, je me suis lancé dans un refactoring. Puis je me suis dit que j’aimerais connaître vos idées de refactoring. Quelles modifications ferriez-vous ? Bien sûr, il ne suffit pas de dire ce que vous ferriez, il faut le prouver avec du code.

Le code de départ est sur Github : le refactoring-challenge. Faites un ou plusieurs refactoring et partagez-nous vos réflexions et résultats.

Amusez-vous bien :).

Dojo@Pyxis

J’animerai un coding-dojo dans les locaux de Pyxis à Laval le mercredi 29 juin prochain de 5pm à 7pm. Et vous êtes tous les bienvenus !

Pour ne pas lutter avec un clavier et un IDE inconnus, apportez votre laptop avec votre environnement de développement préféré prêt à faire rouler des tests.

Pour cette première édition, je vous proposerai une formule que j’utilise lorsque j’aide un groupe à débuter avec les katas. Cela ressemble au déroulement ci dessous.

1. 5′ introduction
2. 15′ présentation du sujet
3. 40′ travail libre en binôme
4. 10′ pause
5. 15′ présentation par un binôme
6. 15′ perfection game par le public
7. 10′ clôture

Habituellement on choisit le binôme qui présente pendant la pause.

A bientôt 🙂

ATTD avec Cucumber

L’exercice proposé ce mois-ci par @12meses12katas m’a donné envie cette fois d’utiliser Cucumber. J’avais dans l’idée d’apprendre à utiliser les Scenario Outline qui sont une alternative intéressante aux tableaux lorsqu’on veut donner plusieurs exemples d’utilisation d’une même formule. Comme je n’avais jamais fait cela, c’était une bonne occasion.

Pour ceux qui ne voient pas de quoi il s’agit, voici à quoi cela ressemble rapidement:

Je voulais rester dans des temps raisonnable pour l’enregistrement vidéo. Alors j’ai essayé de n’écrire que des tests Cucumber, pour gagner du temps. Je n’étais pas très confortable avec cette idée car j’anticipais que j’allais avoir envie d’écrire des tests plus unitaires en cours de route. Cela m’a incité à écouter les tests avec plus d’attention et à programmer par intention.

J’ai vraiment apprécié cet exercice et plus particulièrement:

• Coder dans le train avec Vincent qui a mis à mal la première version de mon modèle,
• La liste de tests capturée sous la forme de scénarios à venir,
• le refactoring de la liste de test qui précise les intentions des tests quand vient le temps de les écrire. Cette activité est homogène à un travail sur un backlog pendant un planning d’itération.

J’ai fait le choix de mettre toutes les classes du domaine au même endroit. Il s’agissait au début de gagner du temps au chronomètre. Finalement cela s’est aussi avéré très pratique en cours d’exercice.

Kata .Net

Que faites-vous le 15 juin prochain après le souper ? Vous êtes les bienvenus dans les locaux de Microsoft à Montréal à partir de 18:30 pour un kata. Amenez de quoi coder pour en tirer le maximum. Plus d’info sur le site de la communauté .Net de Montréal ici.

Classes ouvertes en ruby

Le kata du mois dernier proposé par @12meses12katas m’a encore appris quelque chose. C’était la première fois que je faisais en Ruby le kata bowling. Comme d’habitude je voulais passer sous les 10 minutes avec un code et des tests avec lesquels je sois confortable, c’est à dire qui communiquent leurs intentions d’une manière que je pourrais encore comprendre l’année prochaine.

J’ai commencé par écrire des tests qui ressemblaient à ceci:

describe Bowling do
    specify "spare" do
        claire.sheet = "1/------------------"
        claire.score.should == 10

        claire.sheet = "1/2-----------------"
        claire.score.should == 14
    end
end

J’ai continué tranquillement avec le kata et lorsque j’ai fait passé les tests avec les cas plus complexes avec des spares et des strikes j’ai regardé mon chronomètre et j’ai pris une baffe: 24 minutes. J’ai recommencé plusieurs fois, j’ai posé mon scénario sur une feuille, pour arrêter de perdre du temps à calculer les résultats attendus, j’ai utilisé un raccourcis clavier de plus pour introduire une variable dans RubyMine, j’ai tapé sur mon clavier comme un fou, j’ai mis une table dans les tests, et j’ai péniblement atteint 18 minutes. Bof.

Puis je me suis rappelé du kata des chiffres romains de @jacegu du mois dernier et j’avais bien aimé ses tests qui utilisaient une extension de la classe Fixnum. Alors j’ai essayé de mettre ça en pratique et cela donnait des tests assez différents:

describe Bowling do
    specify "spare" do
        "1/------------------".scores(10)
        "1/2-----------------".scores(14)
    end
end

J’aime mieux cette version des tests qui se concentrent sur le problème à résoudre et supprime le bruit. En plus cela m’a permis de baisser le chrono :).

Kata @onf

Du nouveau dans l’équipe web @onf. On avait déjà fait des randoris et nous avons commencé les katas. Comme l’exercice était nouveau pour l’équipe, nous avons emprunté une structure d’atelier tdd. L’atelier que j’avais en tête était la session de craftsmanship de @slagyr lors du Scrum gathering à Orlando début 2010.

Pendant une rétrospective, l’équipe avait décidé d’explorer les katas le lundi suivant. Je leur ai proposé la structure suivante, répartis sur 1h45:
– 15mn : on regarde une vidéo de kata. En l’occurrencehttp://vimeo.com/16935085
– 45mn : chacun pratique seul ce kata dans le langage de son choix.
– 15mn : pause
– 15mn : quelqu’un se lance et fait le kata devant tout le monde
– 15mn : feedback du public au démonstrateur sous la forme d’un jeu de la perfection

Pendant la pratique, la consigne est de réussir à trouver un chemin qui puisse être parcouru en moins de 15mn.

Etant à l’ONF, Office Nationnal du Film canadien, les analogies évoquées par l’équipe après l’exercice ont tourné autour du film. La personne qui fait le kata s’est retrouvé tantôt réalisateur tantôt héros malheureux malgré lui. Les tests plutôt dans le rôle de l’agresseur. A un moment, un copier/coller malheureux s’est retrouvé être le méchant de l’histoire. Le public l’avait vu, pas le héros…

Ce que j’ai aimé avec cette analogie proposé par l’équipe et nouvelle pour moi c’est l’idée consistant à voir le kata comme un film dans lequel le scénario est autant important que le dénouement, voir plus important. En effet traditionnellement dans un kata, le héros gagne à la fin ; peu de suspence de ce côté. Le public est sensible au scénario, au chemin incrémental choisi par le réalisateur, et apprécie un tableau final original et des émotions fortes en cours de route.

Cela m’a donné envie de scénariser plus mes katas en empruntant des chemins dangereux, en revenant en arrière, … pour finalement gagner tout de même à la fin ;).

Randori pendant l’inter-contrat

En y pensant un moment, il nous est apparu que dans beaucoup de sociétés autour de nous, sociétés de services entre autres, il y avait des consultant en inter-contrat et que « gérer » ces personnes était pour certaines un petit casse-tête. Une des préoccupations souvent évoquée est comment profiter du passage en inter-contrat pour améliorer les compétences des personnes concernées ?

Il y a quelques temps j’ai appelé un ami dans une de ces sociétés et je lui ai proposé de venir animer un coding-dojo pour tous les consultants en inter-contrat de son service. Je me rappelle que lorsque que je lui proposé cela, il a tout de suite été emballé et m’a dit « demain ? ».

Ils m’ont accueilli fin septembre pour animer un coding-dojo randori chez eux et les participants en redemandent. C’était la première fois qu’ils participaient à un coding-dojo alors nous avons dédié 30 minutes, sur les 4 heures, à en parcourir les principes et le fonctionnement. Je me suis limité au rôle d’animateur et de coach TDD. Le soir cela me manquait de ne pas avoir touché le clavier ;-).

Si vous aussi vous avez des inter-contrat et que l’expérience vous intéresse, appelez-nous !