davidbgk
/
larlet-fr-david
Beobachten 1
Favorisieren 0
Fork 0
Code Releases 0 Aktivität
Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Du kannst nicht mehr als 25 Themen auswählen Themen müssen mit entweder einem Buchstaben oder einer Ziffer beginnen. Sie können Bindestriche („-“) enthalten und bis zu 35 Zeichen lang sein.
197 Commits
1 Branch
Struktur: 37d3248b80
Branches Tags
${ item.name }
Erstelle Branch ${ searchTerm }
von „37d3248b80“
${ noResults }
larlet-fr-david/david/blog/2013/tdd-conception-emergente/index.md

index.md 2.9KB
Originalformat Normale Ansicht Verlauf

Add initial content
vor 4 Jahren
​
​
​
​
​
​
​
​
​
​
​
​
​
 1234567891011121314 
  1. title: TDD et conception émergente

  2. slug: tdd-conception-emergente

  3. date: 2013-12-15

  4. 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.

  5. 

  6. 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*.

  7. 

  8. 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 ?

  9. 

  10. 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.

  11. 

  12. 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 ?

  13. 

  14. 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 ?