Quelques Règles de Conception pour la maintenabilité des tests

Règle	Définition	Raison
Un seul objectif à la fois	Un test doit valider une seule fonctionnalité à la fois.	Cela permet de déboguer plus facilement. Cela permet de faire des modifications plus facilement si les règles métiers changent.
DRY (don’t repeat yourself)	factoriser le code de test, éviter les duplications.	Permet de changer le code dans un seul endroit Maintenabilité du code.
Utiliser le langage métier		facilite la communication sur le test
Sortir le code du test	Ne pas parler de la façon dont on interagit avec l’interface dans la description du scénario (CSS, HTML…)	Cela permet de rendre les scénarios métiers plus lisibles : on comprend plus facilement la fonctionnalité à valider.
Réinitialisation des tests	Contrôler les données de tests et pouvoir les réinitialiser à la demande (et au besoin si un test modifie des données).	Cela permet de relancer les tests à la demande.
Indépendance	Les tests peuvent être lancés de façon indépendantes et dans n’importe quel ordre	Lancer un test, plusieurs, ou tous les tests n’a pas d’incidence sur la résultat des tests.
Les tests doivent toujours être verts		Confiance dans les tests. Les tests sont une documentation vivante.
Appliquer des standards de test communs, y compris des conventions de nommage.		Permet une compréhension commune des tests. Permet que de nouvelles personnes prennent en charge les tests.

Nitche as a Tester