Testing

Un test pour place_order a besoin d’une passerelle de paiement, d’un client SMS et d’un calculateur de taxes. Branchez les vraies dépendances, et chaque exécution de test débite une carte et envoie un SMS. Un test unitaire doit s’exécuter en quelques millisecondes, sans réseau : les trois doivent donc être remplacées par autre chose. Cet « autre chose » existe en cinq variantes, chacune résolvant un problème différent, et les traiter comme interchangeables est la raison pour laquelle les débats « mets juste un mock » en revue de code tournent en rond. ...

Un test écrit après le code tend à vérifier ce que le code fait, pas ce qu’il était censé faire. Le développement piloté par les tests (TDD) corrige cela en inversant l’ordre : vous écrivez le test, vous le regardez échouer, puis vous écrivez le plus petit bout de code qui le fait réussir. Comme le test existe avant le code qu’il vérifie, il ne peut pas valider silencieusement tout ce que le code renvoie. Kent Beck a formalisé cette boucle sous le nom red, green, refactor dans son livre de 2002 Test-Driven Development: By Example. Le nom est resté. ...

Une fonction peut avoir 100 % de couverture de tests unitaires, et la page qui l’appelle peut quand même renvoyer une 500 en production. Ce n’est pas une contradiction. Les tests unitaires, d’intégration et end-to-end vérifient des choses différentes, et une suite chargée sur l’un et légère sur l’autre présente un trou précis et prévisible. Ce que vérifient les tests unitaires, d’intégration et end-to-end Prenez une fonctionnalité d’inscription : une fonction valide la saisie, écrit une ligne dans une base de données et envoie un email de bienvenue. Trois tests peuvent la couvrir, et chacun répond à une question différente. ...