Aller à la navigation

Blog

Retour à l’accueil

06 Fév 2020

[DEV] Améliorer sa couverture de tests au sein d’un projet

On ne parlera jamais assez de l’importance des tests au sein d’un projet. Ils ne servent pas seulement à vérifier que la solution que nous avons produit répond correctement au besoin, mais aussi à s’assurer qu’il n’y a pas de régressions lors de l’ajout de fonctionnalités dans la solution.
Parmi les différents types de tests existants, nous nous intéressons ici aux tests unitaires et aux tests de non-régression.

La question que se posent tous les développeurs (du moins ceux qui écrivent les tests) est :
«Comment écrire un test correct et complet ? »

En général, il n’est pas possible de tester une fonction de manière exhaustive en un seul test, c’est pourquoi les développeurs en écrivent plusieurs, voire parfois quelques dizaines pour une même fonction.

Mais comment savoir si je dois écrire un test ? Ou deux ? Ou huit ?
Et bien la réponse est : on écrit autant de tests que de scénarios auxquels on pense. On voit donc apparaître une problématique, qui est qu’on ne teste uniquement que les scénarios auxquels on pense. Pour avoir une couverture de tests plus complète, il faut donc trouver un moyen de tester les scénarios auxquels on ne pense pas.

Les scénarios aléatoires sont un moyen de tester des cas que l’on n’aurait pas pensé. Mais comment vérifier le résultat d’un scénario aléatoire ? 

 

La génération des scénarios aléatoires :

Lorsque l’on parle de générer des scénarios aléatoires, on parle concrètement de tester nos fonctions avec des valeurs générées aléatoirement. Ce sont des tests de propriété (property based testing). Il existe des librairies permettant de faciliter cela (ScalaCheck pour Scala). Elles vont non seulement permettre de générer des valeurs aléatoires, mais vont aussi exécuter le test un certain nombre de fois.

Les différents types de tests

Les tests de validité

Le test de validité permet de vérifier que le résultat est valide, mais pas forcément exact. Un bon exemple pour illustrer ce type de test est de tester la fonction « abs », qui prend en paramètre un nombre et qui doit retourner sa valeur absolue. Ici, on peut très facilement écrire le test qui va vérifier que pour n’importe quel nombre en entrée, le résultat doit obligatoirement être supérieur à 0. Ainsi on ne va pas faire un test pour vérifier que la fonction retourne le résultat exact, mais pour qu’elle retourne un résultat valide.

Les tests d’invertibilité

Ce test va permettre de vérifier qu’en appliquant une fonction à une valeur, et qu’en appliquant ensuite la fonction inverse, on retombe bien sur le résultat de départ. Un exemple concret ici serait d’encoder une valeur, puis de la décoder. On devrait obtenir en résultat la valeur de départ.

Les tests d’idempotence

Nous allons vérifier qu’en appliquant « n » fois la même fonction sur une valeur, on trouve toujours le même résultat. Par exemple, si on prend une liste puis qu’on la trie plusieurs fois avec le même tri, on doit toujours obtenir le même résultat.

Les tests d’invariance

L’invariance est le fait que peu importe l’opération que nous appliquons sur un ensemble de valeurs, cet ensemble doit contenir en résultat les mêmes valeurs. Par exemple, si en entrée nous avons une liste de valeurs, que l’opération appliquée est un tri, la liste retournée doit posséder les mêmes valeurs que la liste en entrée, la différence étant uniquement l’ordre des valeurs.

 

En résumé

Ces types de tests ne peuvent remplacer tous les tests unitaires déjà présents dans un projet, mais sont utiles pour les compléter. En effet, il reste des cas où il est nécessaire de tester une valeur en particulier, puisque l’on n’a pas la certitude que les tests aléatoires vont couvrir cette valeur.

Toutefois, ces types de tests permettent de compléter une couverture de tests existante, ou bien de construire une couverture de tests plus solide. L’utilisation des tests de propriété est donc un atout majeur pour un projet.

 « Failing tests are proof of flaw, successful tests aren’t proof of anything ».

 

article inspiré du scala io 2019 – par Johann Morales, ingénieur big data finaxys

Share our news :

-