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

first - test unitaire
first - test unitaire

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é.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

1 Commentaire

  1. Salut Judicaël. FIRST signifie Fast/Independent/Repeatable/Self-validating/Timely. Parfois, « Independent » est remplacé par « Isolated », mais cela ajoute plus de confusion qu’autre chose. Le qualificatif « Isolé » est bien plus pertinent s’agissant du sujet de test seulement.
    Le critère d’indépendance n’a pas de lien avec 3A (Arrange-Act-Assert), ni Gherkin (Given-When-Then), mais a tout à voir avec l’absence de partage d’état entre tests. 3A et Gherkin peuvent être vus comme des pratiques pour séparer les étapes du cycle de vie standard des tests, pour toutes les formes de test structurées ou scénarisées (https://gearsoftesting.org/test-typology.html).
    Le critère de répétabilité s’applique à découpler les tests de l’environnement d’exécution. À ne pas confondre avec l’indépendance des tests.
    Le dernier critère (Timely, et non Thorough) concerne en fait la conception de concert du code de test et du code de production (cf. TDD), c’est-à-dire que les 3 lois de TDD sont respectées de sorte que le test est écrit avant le code (https://fr.wikipedia.org/wiki/Test_driven_development#Les_Trois_Lois_de_TDD).

    Plus d’informations sur les tests legacy : https://gearsoftesting.org/legacy-tests.html
    Référence bibliographiques concernant les principes FIRST :
    – Clean Code, Robert C. Martin, pp. 132-133
    – Agile in a Flash: Speed-Learning Agile Software Development, Tim Ottinger & Jeff Langr, pp. 94-95

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.