:PROPERTIES:
:ID:       6da0b985-e6f4-4454-bb6a-e941b722365b
:mtime:    20220429104331
:ctime:    20220429093533
:END:
#+title: Test driven development

* Introduction
 * Initialement, cela consistait à écriture les tests avant de coder (/test-first design/),
 * Méthode de dev. logiciel consistant à concevoir un logiciel step by step en :
   * Ecrivant les tests avant la feature,
   * Remaniant le code continuellement.

* Les 3 lois du Test Driven Development

| N° | Lois                                                                                                                |   |
|----+---------------------------------------------------------------------------------------------------------------------+---|
|  1 | Il faut écrire un test qui échoue avant d’écrire le code de production correspondant.                               |   |
|  2 | Il faut écrire une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation.              |   |
|  3 | Il faut écrire le minimum de code de production pour que l'assertion du test actuellement en échec soit satisfaite. |   |

* Processus cyclique de développement

#+DOWNLOADED: https://upload.wikimedia.org/wikipedia/commons/0/0e/Cycle-global-tdd.png @ 2022-04-29 10:17:43
#+ATTR_ORG: :width 800
[[file:Processus cyclique de développement/Cycle-global-tdd_2022-04-29_10-17-43.png]]

** Intérêts
 * Permet préciser le besoin, puis de spécifier le comportement souhaité, avant chaque étape de codage. Le logiciel
   produit répond avec justesse au besoin et est conçu pour le faire avec une complexité minimale => meilleures
   conception et testabilité, et logiciel plus fiable et de meilleure qualité.
 * Chaque test correspond à des modifications du code minimales : un test unique permet de faire un lien évident entre
   une régression et sa cause en cas d'échec.
 * Le rejeu des tests suite à la modification du code permet d'envisager avec sérénité n'importe quelle modification du
   code (transformation - modification qui affecte le comportement - ou d'un remaniement - modification qui n'altère pas le comportement). 
 * Le remaniement régulier permet le réalignement de la conception du code avec les besoins connus, les tests permettant
   de garantir l'absence de régressions.
 * Les tests permettent aussi de documenter le comportement du logiciel.
   
Le TDD fait gagner en productivité de plusieurs façons, il permet de :
 * Eviter des modifications de code sans lien avec le but recherché (focalisation sur la satisfaction d'un besoin précis
   en conservant le cap du problème d'ensemble),
 * Eviter les accidents de parcours, où des tests échouent sans qu'on puisse identifier le changement à l'origine,
 * Maîtriser le coût des évolutions logicielles au fil du temps, grâce à une conception du code perméable au changement,
 * S'approprier plus facilement n'importe quelle partie du code en vue de le faire évoluer (chaque test ajouté explique et documente le comportement du logiciel en traduisant l'intention des auteurs),
 * Livrer une version d'un logiciel avec un haut niveau de confiance dans la qualité des livrables (couverture et pertinence des tests à sa construction).

** Programmation binomiale
Différents usages:
 * Une personne écrit les tests, puis le code et une seconde supervise. Les rôles sont inversés régulièrement,
 * Une personne rédige les tests lorsque la seconde le code.  
 
* Références
 * [[https://fr.wikipedia.org/wiki/Test_driven_development][Wikipedia]]
