Notions de test unitaire et fonctionnel

Vous devez écrire un test qui échoue avant de pouvoir écrire le code de production correspondant.

Vous devez écrire une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation.

Vous devez écrire systématiquement un test après avoir écrit une fonction

Vous devez écrire le minimum de code de production pour que l'assertion du test actuellement en échec soit satisfaite.

Vous devez écrire un test qui réussit avant de pouvoir écrire le code de production correspondant.

Vous devez documenter chaque fonction en s'appuyant sur ses tests si cela est pertinent.

TDD permet de livrer une nouvelle version d'un logiciel avec un haut niveau de confiance dans la qualité des livrables, confiance justifiée par la couverture et la pertinence des tests à sa construction.

TDD permet de produire une documentation plus riche grâce à des tests qui remplacent des paragraphes longs et parfois peu compréhensibles. Cela permet également de ne pas avoir à traduire la documentation car le code est identique quel que soit la langue ou la culture du programmeur.

TDD permet de rendre plus efficaces les fonctionnalités grâce une conception plus consciencieuse du code et de ses modifications futures.

TDD permet d'éviter les accidents de parcours, où des tests échouent sans qu'on puisse identifier le changement qui en est à l'origine, ce qui aurait pour effet d'allonger la durée d'un cycle de développement.