# ? TDD et conception émergente Publié le 15 décembre 2013

On me parle de Test Driven Development depuis des années maintenant et je n’ai toujours pas vu la lumière de la « conception émergente ». J’ai profité de l’Agile Open Sud et d’être entouré de personnes pratiquantes pour faire un point sur les raisons de ce désintérêt au cours d’une session d’OpenSpace.

La première raison, et c’est Rui qui a mis le doigt dessus, c’est que le Web nous offre un moyen de visualiser ce que nous développons très rapidement dans un navigateur. Or, les tests sont un moyen d’avoir un feedback sur notre code : est-ce que le résultat est celui attendu ? Ce qui correspond bien souvent à un simple rafraîchissement de page. Est-ce que la conception émergente se trouve être supplantée par la conception visuelle dans le cas de pages web ?

La seconde est relative à la complexité, le développement d’un site Web avec un framework (bien testé) réduit le périmètre critique qu’il faut valider au cours du développement et ne nécessite pas forcément d’avoir une couverture à 100%. Retester le framework est une perte de temps. La difficulté revient à savoir ce qu’il faut tester en fonction du contexte du projet et de ses spécificités. Il est à noter que le framework masque potentiellement la conception émergente en proposant des contraintes fortes qui guident cette conception.

La dernière est liée au niveau des tests, mon avis actuel est qu’il faut tester la complexité au plus près (unitaire) et la généralité au plus large (fonctionnel), surtout lorsqu’elle vient interagir avec un second langage — JavaScript — ce qui permet de faire d’une pierre deux coups grâce à CasperJS par exemple. Peut-on parvenir à de la conception émergente lorsque le résultat est la combinaison de plusieurs langages intimement liés ?

Finalement, le seul gain réel que j’ai à faire des tests en premier réside dans leur répétabilité, notamment dans le cadre de soumission de formulaires qui peut se révéler être une tâche fastidieuse lorsque réalisée à la main. C’est le seul moment où je commence réellement par les tests mais je crois que c’est plus par flemme de devoir faire le template avant de pouvoir valider mon développement. Il n’y a qu’en codant le client ET le serveur d’une API Web en parallèle que j’en arrive à de la conception émergente. Cela peut sembler éloigné du TDD mais il s’agit pourtant d’un test grandeur nature qui m’en apprend plus que n’importe quel mock… Est-ce qu’il vous arrive aussi de pratiquer du Client Driven Development pour vos API Web ?

### Discussion suite à l’article :

> Est-ce qu’il vous arrive aussi de pratiquer du Client Driven Development pour vos API Web ?

Tout le temps. Dans le sens, où ce que je développe en premier (même pour des petits scripts) est ce qui consomme la donnée (encore inexistante) avant de créer ce qui produit la donnée.

Consumer - Producer.

Ainsi cela permet de maximiser l’efficacité du Producer et de minimiser les fonctionnalités du Producer. Moins de déchets.

Le TDD, j’ai essayé aussi. Le bénéfice que j’ai eu quand j’ai essayé, n’était pas du tout la maintenance du code. Mais plutôt la modularité du code. Les tests forçant à avoir une contrainte plus forte sur les input/output et passage des variables. Bien sûr étant un petit padawan du développement, cela doit être un champ d’horreurs.

Aussi je trouve très difficile de comprendre et je n’ai toujours pas vraiment réussi à faire du TDD au niveau du protocole lui-même plutôt que le message transporté par le protocole.

Karl Dubost, le 2013-12-15 à 18:50

Je pratique le TDD depuis quelques temps déjà. J’ai pu améliorer ma pratique grace au Dojo de dev. Aujourd’hui je ne sais plus faire sans.

Pour moi le TDD me permet de savoir quoi coder. Je ne pense pas a mon code, je pense juste au test, le prochain que je doit écrire. Et c’est ce changement de position qui est, je crois, le plus dur à faire pour ce sentir mieux avec cette pratique, et commencer à voir le principe de "design émergent". A partir du monent ou tu ne penses plus ton architecture/code en "design up-front", ta conception deviens émergente.

C’est très intéressant ce que tu évoque sur les frameworks ainsi que sur le dev web. Voici un déroulé assez classique pour moi (j’esère que ça ne sera pas trop long):

- je dessine la page que je veux voir (html pure, éventuellenement un poil de css)
- je click sur l’action, mais elle ne fait rien (c’est une forme de test unitaire non programmé et non reproductible à l’identique, mais un casper, ou l’enregistrement d’un scénario sélénium le permettrait... il faut que j’essaie)
- Je code l’action la plus simple possible. Si c’est juste une configuration de route, je le fait sans plus de test. Si c’est un code plus complexe, avec des validation et/ou regle métier,:
- je fait un test pour décrire ce que je veux...
- je code
- je refactor
- ...

Je vais m ’arreter là, je pourrais en parler toute la nuit. L’idée pour moi est d’avoir une approche top-down, avec des tests pour m’aider à exprimer ce que je souhaite faire, et non penser directement à ce que je veux coder.

Yannick François, le 2013-12-15 à 23:02

Ce que j’ai cherché maladroitement à montrer ici, c’est qu’à aucun moment je ne refléchi à mon architecture. Fu un temps ou je gribouillais des diag UML ou autre esquisse, mais je ne le fait plus vraiment. Je code par petit pas, en gardant des principes (genre SOLID) en tête pour avancer proprement.

Yannick François, le 2013-12-16 à 11:02