title: TDD et conception émergente
slug: tdd-conception-emergente
date: 2013-12-15
chapo: 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.

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](http://blog.avoustin.com/) [pratiquantes](http://blog.crafting-labs.fr/) 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](http://www.rui.fr/) 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](http://casperjs.org/) 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 ?