Tests unitaires – Coder proprement

Le code de test est aussi important que le code de production

Il existe 3 lois à suivre pour les tests unitaires :

  1. Vous ne devez pas écrire un code de production tant que vous n’avez pas écrit un test unitaire d’échec
  2. Vous devez uniquement écrire le test unitaire suffisant pour échouer ; l’impossibilité de compiler est un échec
  3. Vous devez uniquement écrire le code de production suffisant pour réussir le test d’échec courant

Le test doit avoir le motif BUILD-OPERATE-CHECK

Une assertion par test si possible

Un seul concept par test (donc multiple assertions possible)

Les tests propres suivent cinq autres règles :
Fast (rapide) : les tests doivent être rapides
Independent (indépendant) : les tests ne doivent pas dépendre les uns des autres
Repeatable (reproductible) : les tests doivent pouvoir être reproduits dans n’importe quel environnement
Self-Validating (auto validant) : les tests doivent avoir un résultat binaire : ils réussissent ou ils échouent
Timely (au moment opportun) : Les tests doivent être écrits au moment opportun