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

Ingénieur logiciel, passé du litteraire au scientifique. Toujours curieux, passionné d'IHM, de visualisation et d'experience utilisateur. Chercheur en méthodes pour développer la créativité. Amoureux de la Corée, pays de mon épouse. Diplômé de l'Institut de Formation d'Ingénieur de Paris-Sud XI (IFIPS).