55 lines
3.5 KiB
Org Mode
55 lines
3.5 KiB
Org Mode
: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]]
|