Le sombre état des bibliothèques de tests basés sur les propriétés

• Les tests basés sur les propriétés sont un rare exemple de recherche académique devenue grand public en moins de 30 ans.
• Sous le slogan « n’écrivez pas les tests, générez-les », ils ont reçu le soutien de nombreuses communautés de langages de programmation.
• La page Wikipédia de QuickCheck, à l’origine une bibliothèque Haskell, recense 57 réimplémentations dans d’autres langages.

Enquête sur les bibliothèques de tests basés sur les propriétés

• Les bibliothèques de tests basés sur les propriétés les plus utilisées aujourd’hui sont passées en revue et comparées à l’état de l’art d’il y a 15 ans (2009).
• La plupart des bibliothèques n’offrent pas les fonctionnalités les plus avancées du test basé sur les propriétés.

Pourquoi les bibliothèques de tests basés sur les propriétés sont-elles dans un état aussi triste ?

Les tests basés sur l’état et les tests parallèles ne sont pas aussi utiles que les tests purs

• La modélisation basée sur l’état nécessite une formation.
• Certains avancent que le closed source facilite l’adoption dans l’industrie.

La modélisation basée sur l’état nécessite une formation

• Les tests basés sur l’état et les tests parallèles exigent une manière de penser différente des tests classiques.
• Lorsqu’on met ces outils à disposition de nouveaux utilisateurs, une formation adaptée est nécessaire.

Certains avancent que le closed source facilite l’adoption dans l’industrie

• L’open source n’a pas fonctionné, et l’idée est que des produits closed source accompagnés de services associés favoriseraient l’adoption.

Ce que nous pouvons faire

• Proposer des implémentations open source concises des tests basés sur les propriétés avec état et en parallèle.
• Rendre la partie spécification formelle plus simple afin de réduire le besoin de formation des développeurs.

Résumé des tests basés sur les propriétés purs

• Tester une nouvelle fonction ou une nouvelle fonctionnalité est considéré comme une bonne pratique.
• Par exemple, si l’on écrit une fonction reverse pour inverser une liste chaînée, il est raisonnable de la tester sur quelques listes, comme une liste vide.
• La génération d’entrées aléatoires est la fonctionnalité centrale des tests basés sur les propriétés.
• L’idée est que des entrées aléatoires finiront par découvrir des cas limites.

Tests basés sur les propriétés avec état

• Lorsqu’on teste des composants à état, une même entrée ne produit pas toujours la même sortie.
• Dans les tests basés sur l’état, on génère des séquences d’entrées afin de vérifier comment le système évolue dans le temps.
• Un modèle de référence en mémoire est utilisé pour décrire explicitement l’état.

Exemple : compteur

• Un compteur est implémenté à l’aide d’une variable globale mutable.
• Le modèle est représenté par un entier.
• Le test génère et exécute une séquence de commandes, puis compare la sortie réelle à celle du modèle.

Tests basés sur les propriétés en parallèle

• Les tests parallèles réutilisent le modèle des tests basés sur l’état pour détecter les race conditions.
• Les tests parallèles utilisent un modèle de machine à états séquentielle afin d’effectuer des tests parallèles via la linéarisabilité.

Conclusion et travaux futurs

• Pour améliorer l’état des tests basés sur les propriétés, il faut fournir des implémentations open source et faciliter la rédaction de spécifications formelles.

L’avis de GN⁺

• Cet article explique bien l’histoire et l’état actuel des tests basés sur les propriétés.
• Il souligne l’importance des tests basés sur l’état et des tests parallèles, tout en mettant en avant la nécessité d’implémentations open source.
• Il propose des pistes pour rendre les tests basés sur les propriétés plus accessibles.
• Parmi d’autres projets offrant des fonctionnalités similaires, on peut citer Hypothesis (Python) et PropEr (Erlang).
• Il insiste sur le fait que l’adoption de nouvelles technologies ou de l’open source nécessite formation et accompagnement.

[GN⁺]

Avis Hacker News

• Bonne expérience avec clojure.spec.alpha et test.check
  • hypothesis en Python ne gérait pas les grands ensembles de données, donc abandon de son utilisation
• Le fuzzing basé sur la couverture est bien pris en charge en Go
  • Les tests de fuzzing et les vérifications d’invariants permettent d’obtenir des résultats similaires aux tests basés sur les propriétés
• L’exigence selon laquelle les articles de recherche doivent être reproductibles avec des outils open source peut faire perdre des informations utiles
• Utilisation fréquente de proptest en Rust pour écrire des tests de propriétés basés sur l’état
  • Les tests parallèles sont parfois utiles, mais il peut être plus simple d’exécuter plusieurs tests en parallèle
• Lecture de l’article sur Quviq QuickCheck, mais il peut être préférable d’écrire directement les tests basés sur l’état
  • StateModel nécessite du code de framework supplémentaire, ce qui le rend peu efficace
• Au-delà des machines à états et de l’aspect parallèle, les tests de propriétés basés sur la couverture peuvent avoir un impact plus important
  • Il est important de préserver la réduction automatique tout en maintenant tous les invariants lors de la génération des valeurs
  • L’approche de « réduction interne » de Hypothesis est la plus efficace
• Il existe aussi une bibliothèque QuickCheck basée sur l’état pour Clojure
  • Les tests parallèles ne constituent pas encore un gros problème
• Pour les tests basés sur les propriétés, il vaut mieux les intégrer au système de types lorsqu’il est possible d’écrire des tests rigoureux
  • Pour de simples « smoke tests », il est plus facile d’utiliser des entrées aléatoires
• Il existe aussi QuickCheck Mini, la version gratuite de QuviQ Erlang QuickCheck
• En JavaScript, curiosité de savoir si une bibliothèque de tests basés sur les propriétés permet de générer des valeurs aléatoires qui ne satisfont pas certaines conditions