Comment écrire de bons tests unitaires

Voici une liste de points que je tente de respecter à chaque fois que j’écris des tests unitaires.

  • Ma classe de test teste une et une seule classe à la fois
  • Mes méthodes testent une seule méthode à la fois
  • Mes noms de variables et de méthodes sont explicites
  • Mes tests sont lisibles par un être humain (ou au moins un autre développeur)
  • Mes tests prennent aussi en compte les exceptions
  • Mes tests ne font pas d’accès à la base de donnée
  • Mes tests ne font pas d’accès à des ressources réseau
  • Mes tests respectent les conventions de bon codage (longueur des lignes, complexité,…)
  • Mes tests contrôlent les effets de bords, valeurs limites (max, min) et les variables nulles (même en cas d’exception)
  • Mes tests peuvent fonctionner n’importe ou sans besoin de configuration spéciale
  • Mes tests sont concrets (les dates sont en dur, pas calculées à chaque fois, idem pour les chaines de caractère,…)
  • Mes tests simulent ce qui leur manque : méthodes externes, classes, instances…
Je suis sûr qu’il y a beaucoup à ajouter. Des idées ?

Author: Jean-Baptiste Rieu

Trained software engineer and now product manager. I ❤️ #space #architecture #typography #books #games #verticalfarming. I do #productmanagement #software #abtesting #data. I work on #payment @sundayapp_ Blogging mostly to practice writing, and to engage with others on life in Korea, products, engineering, books and anything worth geeking about.