TDD Workshop

Connaissez vous ce rendez-vous mensuel à Montréal ?

Pendant ces sessions, nous pratiquerons le TDD en jouant à YoseTheGame, un jeu en ligne pour développeurs. Chacun pourra choisir la technologie de son choix. Java, .Net, Python, Nodejs, Php, … Vous êtes tous les bienvenus.

Participer à plusieurs sessions (optionnel) vous permettra de donner à votre entraînement de développeur l’attention qu’il mérite. Ce sera l’occasion de pratiquer l’architecture émergente, le refactoring et bien sûr la livraison de valeur incrémentale. Avec votre laptop et votre IDE préféré prêt à exécuter des tests automatisés, vous voilà fin prêt pour jouer toute la journée.
D’une session à l’autre, vous explorerez plus en détails les différentes manières d’utiliser le TDD, les différents types de tests et, pourquoi pas, un nouveau langage comme une nouvelle corde à mettre à votre arc de développeur.

Catégories :Journal, TDD

#PSD

10 novembre 2013 2 commentaires

Ca y est, j’ai moi aussi un calendrier de formations. Je me concentre sur les formations techniques.

Dans le programme scrum.org, il y a deux versions officielle de la PSD, une .Net et une Java. Dans mes cours, vous pouvez décider de jouer avec l’environnement technologique de votre choix. Il se pourrait que des équipes différentes travaillent avec des langages différents. C’est votre choix. Le seul requis technique est que vous ameniez votre portable équipé d’un environnement de développement. Cela peut être le tout dernier Visual Studio, le tout dernier né de JetBrains ou notre ami Vim.

Dans une PSD, on joue pendant 3 jours avec les différents outils de Scrum, on écrit des tests, on voit du rouge, on voit du vert, on remanie du code sans peur, on étudie différents modèles de code, on lance des débats, on décide ensemble, on demande de l’aide, on fait attention à soi, on apprend à livrer du logiciel dont on est fier. Moi, je suis là pour vous aider à en tirer profit et joie.

Catégories :Journal, Scrum, TDD, The Core Protocols Étiquettes : ,

Learning RegExp

Cette semaine j’ai encore une fois tenté de tirer avantage des regexp pour extraire des paramètres d’une url. Et encore une fois j’ai trouvé cela cryptique. Alors j’ai écrit quelques tests pour explorer les fonctionnalités dont j’avais besoin et je l’ai ai rangé dans un fichier appelé learning.regexp.

C’est une pratique que  l’on essaye ces temps-ci : avoir dans notre harnais de tests, une section, un répertoire, un espace, dans lequel nous décrivons les capacités du langage lui-même. Cela nous permet d’avoir sous la main des exemples d’utilisation qui illustrent les cas qui nous intéressent, sans contexte fonctionnel.

Par exemple, cela peut donner les tests ci-dessous.

Capture d’écran 2013-10-18 à 10.34.31

Catégories :Journal, TDD Étiquettes : , ,

Children Driven Development

15 avril 2013 1 commentaire

La semaine dernière, j’ai rejoué avec plaisir au kata GameOfLife. Mon ambition était de me chronométrer sous la barre des 30 minutes. Après plusieurs occurrences, j’ai été demander de l’aide autour de moi pour améliorer les tests que j’avais écrits.

En regardant la version ci-dessous, mon fils m’a dit « pffuu je comprends rien ».

Alors je me suis mis dans la tête de faire mieux. J’ai secoué mes cellules grises et je suis arrivé à cette nouvelle version.

Cette fois-ci c’est le tour de ma fille de me dire « tu peux pas enlever ces guillemets ? ».

J’avais envie de continuer à jouer en Java et la meilleure idée que j’ai eu à ce moment là était de prendre le chemin consistant à parser un fichier de spécifications. Bien sûr cela demande un peu plus de travail. C’est aussi un bon exercice à faire en se laissant piloter par les tests. Et finalement je suis arrivé à une écriture que mes enfants comprennent beaucoup plus facilement.

Et en écrivant les tests de cette manière, je passe même encore plus facilement sous la barre des 30 minutes. En plus j’ai une pyramide de tests avec des tests dans deux techno différentes, ce qui illustre le point d’écrire des tests avec des formalismes adaptés à des audiences spécifiques.

Merci les enfants 🙂

Catégories :Journal, TDD Étiquettes : , , ,

Help

Bonjour,

A la fin du mois, je vais donner une formation Scrum. Formellement il s’agit de la PSM, une formation de scrum.org dont nous enrichissons le matériel régulièrement, en prenant en compte ce que nous apprenons lorsque nous donnons cette formation. Les inscriptions se font directement sur le site scrum.org : inscriptions

Cette fois-ci sera la première fois que je donne cette formation en tant qu’indépendant. Cela n’a peut être l’air de rien pour vous mais c’est un changement important pour moi. J’ai ouvert cette date au début de l’année, j’avoue sans trop y croire, tant le marché des formations me semblaient déjà bien occupé. Comment faire circuler l’information ? Force est de constater que des personnes s’inscrivent ; mais comment faire mieux ? Et puis ce matin au réveil une idée simple s’est imposée : vous demander de l’aide à vous tous. J’ai besoin de vous, de votre réseau, de vos recommandations. Pourriez-vous donner l’information ? La faire circuler dans vos réseaux ? D’avance, merci.

Autre chose très particulière pour moi, cette session va avoir lieu juste après que j’ai suivi pour la deuxième fois une formation CreatingTime. J’ai déjà suivi cette formation l’année dernière et j’y retourne ! Cela a eu un impact assez fort sur ma manière d’enseigner Scrum. Les outils que l’on étudie dans cette formation sont de mon point de vue de nature à simplifier considérablement l’adoption de Scrum. De même que le TDD propose une voie pour relever le défi proposé par Scrum de livrer de manière soutenable des incréments de logiciels terminés, les outils de la formation CreatingTime propose une voie pour qu’une équipe devienne une équipe performante qui s’auto-organise. Je suis content de pouvoir partager ces outils avec les participants. Je suis sûr qu’après cette deuxième participation, j’aurai de nouveaux éclairages à leur proposer. Scrum comme outil empirique, le TDD pour la partie technique, les Core Protocols & Commitments pour la partie interpersonnelles, un cocktail qui déchire et qui permet aux participants de repartir avec des outils concrets plein leurs poches. Je crois bien sûr que cette approche globale des différents défis proposés par Scrum est un atout majeure de cette session.

Enfin, j’espère faire cette session dans les locaux de l’université à Laval, juste au dessus du métro. J’aime cette idée de faire cette session dans un lieu qui se consacre à l’enseignement. L’université, image pour moi d’un moment où l’on s’autorise à regarder l’avenir en terme d’options ouvertes, où l’avenir nous sourit, où l’on cultive des idées nouvelles.

D’avance, merci.

Catégories :Journal

Javascript TDD n°2

Aujourd’hui j’ai envie de commencer à code un nouveau site web. J’ai déjà en tête plusieurs fonctionnalités, et une première stratégie incrémentale émerge dans mon Backlog. Il est temps d’éprouver ces idées avec du vrai code. Je voudrais piloter mon développement par les tests et mon premier test va décrire que je voudrais un site qui se déclare lui même en construction.

Ce que j’aime dans ce premier test c’est qu’il va me permettre d’explorer plusieurs éléments complémentaires. Du côté des tests, comment écrire un test qui simule l’accès à une page par un navigateur et contrôle le contenu de la page servie ? Du côté du code de production, comment écrire un serveur web en Javascript ? Côté tests, je vais explorer l’outil Zombie. Côté code de production, je vais explorer les outils disponibles nativement dans Node.

L’utilisation de Zombie se révèle assez facile et j’ai rapidement mon premier retour de test.


Sans surprise car notre test ne démarre pas encore de serveur capable de répondre à la requête faite par Zombie. Notons au passage que cette façon d’écrire le test ne conduit pas à recevoir un code d’erreur 404 auquel on pourrait s’attendre dans ces conditions. Avec le 404, j’aurais eu deux étapes. Une première pour répondre, ce qui aurait changé mon message d’erreur et produit le message d’erreur ci-dessus. Et une seconde pour implémenter la réponse attendue. Là où nous sommes actuellement.

Aujourd’hui je veux faire passer ce test en utilisant Node. J’oublie ici les serveurs écrits par dessus Node qui existent car je voudrais jouer à en apprendre plus sur Node lui même et ses possibilités natives. La bonne nouvelle c’est que dès la page d’accueil de Node, on nous présente une manière de faire.

En gardant juste le code nécessaire pour faire passer mon test, j’obtiens mon premier vert. J’ai enlevé le code qui met des choses dans l’en-tête parce que je n’en ai pas besoin pour faire passer ce test.

Je suis content de ce premier vert. Qu’est-ce que j’ai appris ? Démarrer un serveur http avec Node semble facile. Avec le code que j’ai enlevé j’apprends que je vais pouvoir contrôler les codes de retour, le type du contenu. Cela me rend confiant que je vais éventuellement pouvoir servir des feuilles de styles, des scripts, des images, bref tout ce que je sens que je vais bientôt avoir envie de servir.

Pour l’instant, je n’ai rien à déployer car tout le code se trouve dans les tests. Pour pouvoir pousser ce code en production quelque part, je dois extraire du test cette fonctionnalité de serveur. J’ai l’habitude de commencer par des ExtractMethod. J’en fais deux de suite en essayant de me concentrer sur les deux intentions disjointes que j’identifie. Mon test et mon presque-code-de-prod se séparent un peu.

Le code de test est ainsi plus concis. Je suis confortable à ne pas pousser plus loin pour l’instant. J’anticipe que j’aurai bientôt envie d’extraire ce code html dans un fichier .html séparé, de rendre mon serveur plus intelligent pour qu’il sache servir ce fichier, qu’il sache servir des fichiers statiques en général. Bien sûr je ne suis pas le premier à faire ça et une recherche rapide me donne plusieurs pointeurs sur des modules Node qui font déjà tout ça et que je pourrais utiliser. Mais où serait le plaisir ?

Pour l’heure, il me reste à déplacer ce code dans des fichiers séparés du code de test pour pouvoir les déployer. Quelque chose qui ressemble à un ExtractClass mais pour une application Node. La chose amusante c’est qu’une façon de faire fonctionner cette extraction en modifiant le  code le moins possible consiste à mettre en place le formalisme ci-dessous qui justement emprunte la sémantique O-O ; ce qui est cohérent avec une extraction de classe.

httpserver.js

site.spec.js

Notez que le new est inutile ici mais je le conserve car je trouve qu’il illustre mieux mon intention. Inutile c’est à dire que si je l’enlève, le test passe toujours.

Comme vous vous y attendez certainement, ce code ne donne pas le résultat souhaité lorsque qu’on l’exécute en production. En effet, le navigateur manque d’information et affiche le code html renvoyé.

La directive Content-Type que j’ai supprimé est finalement très utile ;). Jouons le jeu et ajoutons le test qui nous invite à l’ajouter.

Bien sûr il suffit ici de positionner correctement le Content-Type et le tour est joué.

Pour déployer sur Heroku, quelques ajustements sont nécessaires. Pour les curieux, notez que je déploie à partir de la branch deploy-heroku. Dans la prochaine étape, je prévois d’extraire le code html dans un fichier maintenance.html qui sera servi par défaut. Tout cela piloté par des tests bien sûr.

stay tuned! 😉

Le site: http://work-equals-play.herokuapp.com/

Le code: https://bitbucket.org/ericminio/work-equals-play

Le Backlog: https://trello.com/board/work-play/5140ca7e6abb829939000135

 

Catégories :Journal, Scrum, TDD Étiquettes : , , ,

Javascript TDD n°1

Dans ce classique PrimeFactors kata, plusieurs versions du code production peuvent émerger : la double boucle, la voie récursive et, puisque Javascript le permet, une approche plus fonctionnelle.

1. Ouverture

Capture d’écran 2013-03-10 à 18.11.05

Capture d’écran 2013-03-10 à 18.23.00

Ce premier test permet de nous mettre d’accord sur notre objectif. Il simule une discussion avec un expert du métier qui nous expliquerait quoi attendre de la décomposition d’un nombre en prenant un exemple au delà des premiers chiffres. Nous commenterons bientôt ce test pour passer à des étapes plus simples mais pour l’instant nous allons juste l’écouter.

Ce premier retour nous invite à créer la fonction primeFactorsOf.

Capture d’écran 2013-03-10 à 18.30.26

Capture d’écran 2013-03-10 à 18.31.39

Ce nouveau retour nous plonge dans le sujet. Un test d’un cas plus simple va nous permettre de nous mettre sur les rails du kata. En considérant que le nombre 1 ne se décompose pas en facteurs premiers, nous écrivons un autre test qu’il est facile de faire passer en renvoyant naïvement un tableau vide. En commentant notre test ultime, nous avons notre premier vert.

Capture d’écran 2013-03-10 à 18.29.03

Capture d’écran 2013-03-10 à 18.39.31

2. Développement

Notons que nous avons déjà de la duplication dans les tests. Nous sommes au vert et cela pourrait être un bon moment pour la supprimer. Néanmoins comme notre test ultime est commenté, nous n’aurions pas forcément de retour de tests nous confirmant que nous n’avons rien cassé. Je décide donc d’attendre encore un peu, et je plonge dans l’étude des facteurs de 2.

Selon vos préférences, votre code pourrait évoluer selon des chemins assez différents.

Il y a la voie des boucles

Capture d’écran 2013-03-10 à 23.38.09

la voie récursive

Capture d’écran 2013-03-10 à 23.40.37

Et une voie encore récursive légèrement différente  qui pourrait mener à un code d’allure plus fonctionnelle.

Capture d’écran 2013-03-10 à 23.42.16

Nous commençons à avoir de la duplication un peu partout. C’est à dire dans le code de production et dans le code de test. Cette dette s’est accumulée plus rapidement dans le code de test et il est temps de la payer.

Capture d’écran 2013-03-11 à 08.16.16

Une première modification nous permet de réduire l’empreinte visuelle de la duplication sans la supprimer. Il ne reste plus qu’à, par exemple, boucler sur une collection.

Capture d’écran 2013-03-11 à 08.29.06

La duplication est aussi présente dans le code de production. Dans les trois chemins présentés plus haut, le chiffre 2 est présent plusieurs fois. Si par exemple je continue avec le dernier des trois, j’ai plusieurs options pour la supprimer. J’en suis une qui en deux coups m’amène à un code que je trouve élégant.

Capture d’écran 2013-03-11 à 08.46.56

3. Fin de partie

Toutes nos pièces sont maintenant confortablement installées et nous voilà à deux coups de conclure. Le 3 passe sans difficulté et nous ouvre la voie pour le 5 qui termine par un second appel récursif. Notre test ultime est maintenant libre 🙂

Capture d’écran 2013-03-11 à 08.54.00

Capture d’écran 2013-03-11 à 08.54.40

Catégories :Journal, TDD Étiquettes : , , ,