Dans cet article, nous allons nous intéresser à la valeur des tests automatisés. En effet, chaque test a une valeur et un cout.

C'est à dire, comment ils permettent de résoudre leurs problèmes métiers. La valeur ajoutée est elle systématique ? En tant que développeurs, comment pouvons nous rédiger les tests les plus utiles possibles ?

L'argent ne pousse pas sur les arbres. Les tests non plus

Chaque test a une valeur et un cout.

• Sa valeur est représentée par sa capacité à réduire les risques lors des développements.

• Son coût est est le temps de travail nécessaire à sa mise en place et à sa maintenance.

Le coût de maintenance ne doit pas être sous-estimé, un test complexe et prompt aux erreurs devra souvent être re-analysé et modifié.

Impact : un test qui détecte des bugs à impact fort a plus de valeur qu'un test qui détecte des bugs très mineurs.

Cela ne veut pas dire qu’il ne faut pas tester les bugs mineurs. Il faut cependant jauger le coût d'un test pour rester rentable.

NB: les tests manuels sont très onéreux car chaque exécution induit des coûts supplémentaires

Quels facteurs rendent un test plus ou moins rentable ?

Il existe plusieurs facteurs qui peuvent affecter la rentabilité d'un test.

L'objectif de cet article est de mettre en lumière les facteurs principaux et de tenter de fournir des solutions permettant de rendre nos tests plus rentables

Le diagnostique, c'est pas automatique

En cas d’erreur, le test doit être capable de décrire précisément le bug rencontré. Pour se faire, un test doit se concentrer sur un composant précis et le tester indépendamment.

Exemple : Dans un formulaire, tester le fonctionnement d’un champ en particulier sans se soucier de la valeur des autres champs (ie. y insérer des cas nominaux).

Cette notion est appelée le périmètre d'un test. Généralement, on souhaite créer un test avec le **périmètre le plus petit possible". De cette façon, si quelque chose casse, on sait exactement quoi.

Exemple d'un petit périmètre :

[Contexte]
J'ai un service backend qui récupère des montants notes de frais depuis une API externe, calcule le total Hors Taxes des montants et les enregistre en base de données.

Je souhaite rédiger un test automatisé qui vérifie que le calcul de total Hors Taxes est correct.

[Décision]
La valeur de ce test réside dans la vérification du calcul TTC -> HT. 
Vérifier le fonctionnement de l'API et de la BDD n'apportent aucune valeur à mon test. 

Je choisis de les exclure de mon périmètre de test.

Connaissez vous la définition de la folie ?

La folie c'est faire la même chose encore et encore et s'attendre à un résultat différent

Si vous avez déjà eu un test qui, entre deux exécutions, produit des résultats différents, alors vous êtes familier avec cette définition.

Il arrive qu'un tests puisse avoir des résultats différents entre plusieurs exécutions. On appelle ses tests "flaky tests" ("friables" ou "peu fiable" en français).

Ce type d'irrégularité peut apparaitre lorsque le périmètre du test est trop large (i.e. trop de variables entrent en jeu) ou si le scénario de test n'est pas assez précis.

Si vous rencontrez ce genre de problèmes, isolez les variables, simplifiez le test voir diviser le en plusieurs

Un test n'est rien d'autre qu'une spécification

Comme nous avons déjà pu le dire, un test permet de vérifier le bon comportement d'une fonctionnalité.

Cependant, son usage ne se limite pas là. Il peut aussi servir de documentation pour les équipes de développement. En spécifiant le comportement attendu, il jour aussi le rôle de... spécification.

Il est possible de faire gagner de la valeur à un test en le traitant comme une spécification. Un test peut paraphraser la spécification fonctionnelle et documenter, en détail, le comportement attendu.

Récapitulatif

Maintenant que nous avons abordé les notions théoriques affectant la valeur d'un test, je vous propose un court récapitulatif d'actions et de concepts à garder en tête pendant la rédaction de vos tests.

Note : ces instructions sont valables pour des tests automatisés ou manuels

Caractéristiques d'un "bon" test

• A des instructions claires sur quand et comment l'exécuter
• Spécifie le résultat désiré
• Spécifie les résultats non désirés
• Isole correctement la fonctionnalité testée (on sait d’où vient le bug)
• Est basé sur les spécifications et non sur l’implémentation
• Documente clairement son fonctionnement et son objectif. Si une fonctionnalité change, les tests liés doivent être modifiables simplement
• Vérifie les comportements courants en premier

Caractéristiques d'un "mauvais" test

• N’est pas documenté ou ne peut être exécuté que par quelqu’un familier avec la fonctionnalité testée
• Donne des résultats non reproductibles
• Ne couvre que les cas nominaux
• Utilise une méthodologie différente du reste du catalogue de test
• Nécessite des modifications de l’environnement qui ne sont pas réalistes (~ ne correspondent pas à la production)