> Attention, ceci est une page de théorie pure ! Si ça te semble un peu trop pour l'instant, n'hésite pas à passer à la section suivante pour un **exemple**.

##### Comment développer une application fiable et maintenable ?

C'est une question importante, à laquelle le TDD apporte une réponse. TDD signifie **Test-Driven Development**, ou en français **Développement piloté par les tests**.

<img src="https://media.giphy.com/media/g8XkcuerwzVS0/giphy.gif" alt="collapse" style="float: left; padding: 0 25px 25px 0;" />

Les applications informatiques ont des durées de développement - et de "vie" - variées. Certaines peuvent être développées en continu sur des années !

Il est donc primordial de pouvoir **maintenir et faire évoluer** le code, sans "casser" ce qui existe.

Cela n'a pas toujours été simple, et de ce fait, bien des projets se sont **terminés en désastres** techniques et financiers.

L'approche TDD inverse le cycle "traditionnel" de développement.

Auparavant, on planifiait beaucoup :
- Spécification fonctionnelle pour exprimer ce que devait faire l'application (du point de vue de l'utilisateur).
- Spécification technique pour détailler les technologies qu'on prévoyait d'utiliser.
- Etc., etc.

On pouvait y passer beaucoup de temps, et pour autant, cet effort de réflexion ne permettait pas toujours d'anticiper certains "pépins" rencontrés dans la pratique.

Le TDD a une portée résolument *pratique* et utilise quelques concepts simples :
- Avant d'écrire du code pour *faire* quelque chose, on écrit *d'abord* un test qui va **vérifier que le code qu'on écrit va se comporter comme on l'a prévu**.
- Au lieu de planifier énormément de choses en amont, on cherche d'abord à créer un **produit minimal** utilisable par des utilisateurs. A partir de cette base, on ajoute des fonctionnalités de façon *incrémentale*, par petites touches.

Le fait d'**écrire les tests en premier** a une conséquence logique : quand on lance les tests juste après les avoir écrits, ils échouent ! Et c'est voulu ! Une fois qu'on a un test qui échoue, on écrit le code qui permet de faire passer le test.

> Attention, "moins planifier" ne signifie pas non plus "se plonger tête baissée dans le *cooooooode*", sans réfléchir :).

D'ailleurs, d'une certaine façon, les tests servent à la fois de spécification et de documentation du code. Ecrire des tests nous aide à clarifier notre intention, avant de nous attaquer au code de l'application proprement dit.