Weekly backup.

20220429093533-test_driven_development.org

@@ -0,0 +1,54 @@
+: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]]