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.

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

 

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

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.

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.

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

la voie récursive

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

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.

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.

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.

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 🙂

Vacances :)

En traversant en ferry depuis l’île du Prince Edouard vers la Nouvelle Ecosse, il y avait le wifi. J’ai trouvé ça trop fun. Emporté par mon élan je me suis mis à coder pour préparer une session que je voudrais proposer aux conférences d’automne. M’aideriez vous à la paufiner en me donnant votre avis sur ce qui suit ?

Je voudrais reprendre l’idée du kata classique de la décomposition en facteurs premiers en l’enrichissant d’un accès web à la décomposition. Mon intention est de rendre plus palpable l’intérêt du tdd en prenant un cas simple que probablement tout le monde connait; et en le mettant dans ce qui pourrait ressembler à une vraie application.

Je pourrais dans cette session illustrer les points suivants.

• outside-in vs. inside-out tdd
• architecture hexagonale
• build unique avec tests JUnit et Jasmine
• gestion de sources avec Mercurial

Dans ce ferry donc, j’ai juste le temps de poser deux tests différents pour illustrer le premier point. J’ai commencé par le coeur dans une branche inside-out. Le départ ci-dessous n’est pas vraiment le départ classique du kata mais le kata en question n’est pas mon sujet ici.

Puis, dans une autre branche, je repars à zéro et je pose un test web plus ambitieux que le précédent.

Je me retrouve ainsi avec deux débuts d’histoires différents. La seconde histoire a le mérite de partager mon intention cible qui est de donner un accès web la décomposition. Ces deux approches ne sont pas obligatoirement opposées. Il peut arriver que l’on ait besoin d’explorer un domaine, juste pour en apprendre un peu plus et sortir du brouillard.

Je ne pense pas écrire tout le code pendant la session mais plutôt arriver avec un répo Mercurial qui contient les deux histoires, qui fusionnent à un moment d’ailleurs, et de passer les histoires en accélérée en sautant d’une révision à l’autre pour illustrer les points listés plus haut. Comme on le voit dans les descriptions ci-dessus, je prévois de sauter d’un test rouge à l’autre, le point n’étant pas de faire passer les tests mais d’illustrer que les tests nous guident ; les tests rouges bien sûr !

Qu’en pensez-vous ? Devrais-je proposer cette session ? Que devrais-je améliorer ou modifier pour proposer une session de ce type ? Avez-vous besoin d’en savoir plus pour avoir un avis ?

 

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.

Remove comments

Aujourd’hui j’ai vu du code qui ressemblait à celui ci-dessous. Bien sûr ce n’était pas vraiment ce code mais l’idée est là.

Nous avons discuté de l’idée de supprimer ces commentaires. Une décision pas facile à prendre dans l’état car, pour plusieurs personnes présentes, le dessin du commentaire a beaucoup de valeur. En effet, il résume le cas qui nous intéresse de façon très claire.

Cela devient pourtant une décision facile à prendre si tout simplement on décide de reproduire ce dessin dans le code. Après un peu de tuyauterie, je suis récompensé. Ci-dessous un exemple de ce que cela peut donner.

Bien sûr il reste à ranger tout ça plus proprement mais vous voyez l’idée. Notez que dans la bataille on est passé de 2 tests à 1 seul.

Et vous, vous faites comment ?

Refactoring de tests

Salut 🙂

Je faisais remarquer aux participants d’une PSD le mois dernier que l’on passe énormément plus de temps à lire du code qu’à en écrire. C’est pour cette raison, entre autres, que je leur conseillais d’investir dans la lisibilité du code. Une façon de faire ça qui fonctionne bien pour moi c’est d’écrire l’intention du test en langage naturel, puis de m’arranger pour faire compiler et passer ce que je viens d’écrire.

Un exemple ? Allez, un exemple… 😉

Considérez le test suivant. Sans doute vous trouverez que j’exagère de montrer autant de choses qu’il ne faut pas faire, mais c’est pour l’exemple.

Le défaut de ce test qui m’intéresse aujourd’hui c’est que beaucoup de gens vont le lire plusieurs fois pour bien comprendre son intention. Si j’essaye de me concentrer sur l’intention du test, en tentant d’activer mon meilleur anglais, cela me donne envie d’écrire les choses plutôt comme ci-dessous.

A partir de là, je dis souvent aux participants « il ne vous reste plus qu’à placer les parenthèses et les points où cela vous arrange pour faire compiler tout ça ». Il y a bien sûr plusieurs façons de le faire et je ne vais pas m’étendre sur ce point. Juste mentionner que pour ma part j’aime bien le pattern builder et, en Java, les imports statiques. Cela peut par exemple donner le résultat ci-dessous.

C’est plus clair non ?

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 :).

#tdd at school

J’ai eu la chance plusieurs fois de discuter avec des professeurs qui enseignent le Java à l’université. Nous discutions d’intégrer le tdd à l’enseignement.

Une approche consiste à intégrer le tdd à la fin de l’enseignement. J’ai d’ailleurs eu la chance de participer à cette approche en allant enseigner le tdd dans plusieurs universités. En pratique ce sont les dernières années qui en ont profité puisque cette approche suppose qu’il faut tout d’abord apprendre un langage puis apprendre le tdd.

Une autre approche consiste à intégrer le tdd tout au long l’apprentissage. J’ai eu la chance d’assister à plusieurs des cours donnés par ces professeurs et ce qui m’a frappé c’est la manière utilisée pour avoir du feedback sur un code. Typiquement les étudiants exécute un programme et regardent les traces envoyées dans la console. L’idée est bien sûr de modifier cette habitude et d’utiliser des tests pour avoir du feedback sur le code.

Pour rendre cela concret, nous avons pris le sujet du cours qu’il venait de donner, un cours sur l’héritage et le polymorphisme en Java, et nous avons écrit le test ci dessous.

@Test public void
showPolymorphism() {
    Vehicle bicycle = new Bicycle();
    Vehicle car = new Car();
    assertThat( bicycle.wheelCount(), equalTo(2) );
    assertThat( car.wheelCount(), equalTo(4) );
}

Les professeurs ont vite imaginé comment ils pourraient grandement simplifier leur travail de correction ;).

L’utilisation des tests est ici bien différente. Au lieu de considérer le tdd comme une approche à part, nous l’intégrons tout au long l’enseignement. Les praticiens du tdd le savent et l’écrivent souvent : le tdd est parfait pour apprendre un nouveau langage. Alors pourquoi pas à l’école ?

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 🙂