F.I.R.S.T avec nos tests unitaires

Connaissez-vous l’acronyme F.I.R.S.T pour les tests unitaires ? Je vais profiter de cet article pour vous en parler car elle n’est pas encore très connue et pourtant très intéressante.

Qu’est-ce des tests unitaires F.I.R.S.T ?

Dans le même style que l’acronyme I.N.V.E.S.T. utilisé pour rappeler quelques règles utiles pour les user-stories, l’acronyme F.I.R.S.T. permet également de rappeler des règles pour les tests unitaires.

Je la trouve très intéressante et je pense qu’elle mérite d’être connue. Voici l’explication complète de cet acronyme F.I.R.S.T.

F.I.R.S.T : F pour Fast

Le développeur ne doit pas hésiter à lancer ses tests unitaires parce qu’ils sont long à lancer.

Ces tests doivent pouvoir inclure la configuration, des tests très rapides (quelques millisecondes) afin d’avoir la capacité de faire des milliers de tests sans contrainte de temps.

F.I.R.S.T : I pour Independant / Isolated

Il est conseillé d’utiliser la méthode des 3A (Arrange, Act, Assert) que je vais expliquer de suite.

Arrange

Les données que l’on utilise dans les tests ne doivent pas être dépendantes de l’environnement sur lequel on fera tourner ceux-ci. Il est essentiel de bien organiser< ces données par rapport au test.

Act

Il faut Invoquer la méthode réelle testée

Assert

On va faire en sorte de tester une seule assertion logique sur chacun des tests que nous faisons. On ne testera qu’un seul objet bien que dans certains cas, une action pourra mettre à jour plusieurs objets.

Conseils

Évitez de faire des assertions dans la partie Arrangement, laissez-le lancer des exceptions et votre test échouera quand même.

Ces tests doivent pouvoir se lancer individuellement ou en série de la même façon. Un test ne doit pas être dépendant des autres tests.

F.I.R.S.T : R pour Repeatable

Quand le test se lance, il ne doit pas dépendre des autres tests ou d’éléments extérieurs. Les résultats obtenus doivent toujours être les mêmes afin de s’assurer de la fiabilité des retours de celui-ci.

Les données devront donc être préparées par le test lui même pour s’assurer d’être en capacité de répéter le test régulièrement sans avoir de mauvaises surprises.

F.I.R.S.T : S pour Self-validating

Le test doit être capable de vérifier lui même les résultats automatiquement. On évitera les vérifications humaines qui peuvent devenir rapidement chronophage et parfois amener à l’erreur (dû souvent à une lassitude de répéter régulièrement les mêmes tests).

F.I.R.S.T : T pour Thorough

Le test devra couvrir l’ensemble des cas de tests et non couvrir 100% des données. La raison est simple: en couvrant 100% des données, nous aurions des tests trop longs qui pourraient durer des jours à chaque exécution.

Pour approfondir la qualité de nos tests, voici quelques astuces à suivre :

• tester les limites applicatives
• utiliser des volumes de données conséquents et représentatifs de la réalité
• tester les différents types d’utilisateurs de l’application pour s’assurer que les droits sont biens définis (sécurité des données)
• utiliser des valeurs proches des limites gérées par les types utilisés (erreurs de débordement et de débordement des types de données comme un entier)
• tester les exceptions et les erreurs
• tester des arguments erronés

Conclusion F.I.R.S.T

J’espère que cet acronyme vous sera d’une grande aide pour faire des tests unitaires de grande qualité. La qualité technique est essentielle dans un produit agile afin d’assurer un service continue de grande qualité.