Ce que je tente d’expliquer pendant les cours de Test-Driven Development (TDD) c’est que le TDD est une approche générique pour aborder un développement logiciel. “Malheureusement”, quand on lit “TDD”, on comprend souvent tests “unitaires”. Sans doute parce qu’historiquement les premiers tests écrits en suivant cette approche ont été des tests “unitaires”. Mais le concept peut se voir plus globalement. Par exemple si on ne prend les deux cours suivants proposés par Pyxis:

  • Test-Driven Development
  • Specifications exécutables avec GreenPepper

Le premier propose des ateliers d’écriture de tests automatiques écrits avec un framework xUnit alors que le second se concentre sur l’écriture de tests automatiques écrits avec GreenPepper. En lisant plusieurs forums je réalise que certains contributeurs classeraient sans doute naturellement le premier dans une case TDD et le second dans une case DDD, voire BDD. En fait les deux cours appartiennent à la catégorie TDD. “Test-Driven” est seulement une autre manière de dire : définissons ce que nous attendons sous la forme d’un test. Pour moi – je suis ScrumMaster 😉 – cette approche est similaire à avoir une définition de “terminé”. Cette façon de nous exprimer pourrait d’ailleurs nous emmené sur plusieurs branches si nous poursuivions l’analogie avec Scrum. Quel est votre fil de penséé ? tests->liste de tests->backlog de tests->specifications exécutables->Product Backlog ?

gabriel bélanger

Billet précédent

Suivez Pyxis sur Twitter

Billet suivant

Quel outil utilisez-vous pour développer vos sites internet?