index.md 2.9KB
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 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 ?