Accueil > Journal, Scrum, TDD > Javascript TDD n°2

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

 

Publicités
Catégories :Journal, Scrum, TDD Étiquettes : , , ,
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :