Comment les tests unitaires de goyave ont-ils été générés automatiquement?

31

La goyave a des cas de tests unitaires générés automatiquement :

La goyave a un nombre impressionnant de tests unitaires: en juillet 2012, le package de tests de goyave comprend plus de 286 000 cas de test individuels. La plupart d'entre elles sont générées automatiquement , pas écrites à la main, mais la couverture des tests de Guava est extrêmement approfondie, en particulier pour com.google.common.collect.

Comment ont-ils été générés? Quelles techniques et technologies ont été utilisées pour les concevoir et les générer?

dzieciou
la source
Je me souviens avoir vu un discours d'un type de Google qui a touché ce sujet. Aucune idée du nom cependant, la conférence a eu lieu lors d'une convention java, je pense
Zavior
3
Le package com.google.common.collect.testing a beaucoup de classes avec "Generator" dans leurs noms - ce qui en fait un framework pour la génération de tests. Il y a aussi des sous-packages avec des classes documentées comme "squelettes" ou "classes de base" pour les tests ...
gnat
1
@gnat Oui, j'étais sûr de l'avoir vu quelque part. com.google.common.collect.testing.features, par exemple, montre les caractéristiques / contraintes qu'une classe de collection doit satisfaire, et un cas de test est une combinaison de celles-ci. De cette façon, ils peuvent paramétrer les tests
dzieciou
Vous aurez peut-être plus de chance en matière d'assurance et de test de la qualité des logiciels.SX
Monica - M. Schröder
La question a retenu l'attention de la communauté, mais aucune réponse raisonnable jusqu'à présent, j'ai donc suivi la suggestion de Martin et je l'ai mise ici: sqa.stackexchange.com/questions/5214/… .
dzieciou

Réponses:

8

Une grande partie de cette masse de tests concerne les implémentations de la collection Guava. Ils ont écrit des tests génériques qui testent de manière exhaustive les interfaces de collecte, ce qui génère une suite par implémentation. Voir, par exemple, des classes appelées CollectionAddAllTester, ListIndexOfTester.

Tout cela est soutenu par une bibliothèque appelée testlib, livrée avec Guava. C'est assez générique. Il prend en charge l'écriture de tests génériques pour n'importe quelle interface (pas seulement les collections). Vous pouvez spécifier Features des implémentations possibles et les tester (par exemple, si votre ensemble est non modifiable, vous attendez un résultat différent set.add()), et lorsque vous exécutez les tests, vous spécifiez les fonctionnalités prises en charge par votre implémentation.

Il est basé sur JUnit 3, et non sur 4. Normalement, vous avez une classe étendue TestCasepleine de méthodes nommées testSomething(), et JUnit les exécute de manière réfléchie. La bibliothèque testlib se connecte à l'exécution de ces tests afin que le cycle de vie ressemble à ceci:

  • Pour chaque implémentation que vous souhaitez tester
  • Pour chaque méthode d'essai (applicable)
  • Créer l' TestCaseinstance
  • Initialisez le TestSubjectGenerator- c'est l'interface testlib que vous étendez là où vous créez réellement le sujet de test
  • Exécutez de manière réfléchie la méthode de test. Pendant cette méthode, getSubjectGenerator()donne accès au sujet du test

Le bit clé est l'étape d'initialisation supplémentaire qui leur permet d'injecter un sujet de test spécifique dans le cas de test générique.

J'ai écrit un article sur la façon d'écrire des suites de génération de testlib pour vos propres interfaces.

(Également publié sur la même question sur le site sqa .)

Joe Kearney
la source
6

Il existe des générateurs de tests unitaires. Par exemple, dans le monde .NET, quelque chose comme Microsoft Pex pourrait le faire.

Par exemple, Microsoft Pex essaie en se basant sur l'analyse de code toutes les valeurs possibles comme arguments pour une méthode. Certains arguments devraient laisser la méthode lever une exception. De telles choses peuvent automatiquement créer des tests pour. Les valeurs statiques comme une chaîne vide renvoyée dans certains cas peuvent également être testées automatiquement.

Sebazzz
la source
2
Il s'agit d'un test aléatoire utile uniquement pour le test de chemin négatif (exceptions, entrée non valide, crash-es, délai d'attente). Je crois qu'ils ont également généré des tests pour Happy Path, et cela nécessite plus de conception, pas seulement le lancement d'un outil d'analyse statique.
dzieciou
Et je sais qu'il existe des moyens et des outils pour générer un test de chemin heureux (par exemple, voir cette réponse ), mais je suis intéressé par la façon dont cela a été fait dans le cas particulier de la goyave
dzieciou