Tests paramétrés - Quand et pourquoi les utilisez-vous?

Récemment au travail, nous avons eu quelques divergences d'opinion concernant les tests paramétrés . Normalement, nous utilisons un style TDD (ou du moins essayons de le faire), donc je comprends les avantages de cette approche. Cependant, j'ai du mal à voir les tests de gain paramétrés apporter. Pour référence, nous travaillons sur un service et ses bibliothèques qui sont exposées via une interface RESTful.

Ce que j'ai vu jusqu'à présent, ce sont des tests qui, au moins utilisent JUnit dans Eclipse:

• Manque de détails - lorsqu'un test échoue, il est très difficile de voir les paramètres qui l'ont provoqué.
• Souvent compliqué à créer
• Ont tendance à être créés après que le code a été écrit - strictement pas un inconvénient en tant que tel, mais les gens partent-ils avec des tests paramétrés à l'esprit lorsqu'ils commencent un morceau de code?

Si quelqu'un a des exemples où ils sont vraiment utiles ou même de bons conseils pour les utiliser, ce serait fantastique. Je veux m'assurer que je ne suis pas seulement obstiné parce que personnellement, je ne choisis pas de les utiliser et de voir s'ils sont quelque chose que nous devrions envisager de faire partie de notre arsenal de tests.

Le problème avec le test de n'importe quel logiciel est que la complexité explose assez rapidement. Le fait est que vous ne pouvez pas tester toutes les combinaisons possibles de paramètres passés à vos méthodes. Phadke préconise une approche de conception d'expériences (DOE), qui permet de générer la liste probable des valeurs de paramètres qui doivent être testées.

L'idée est que, même si vous ne testez pas de manière exhaustive, la plupart des défauts provoquent une "région de défaut" plutôt qu'un défaut ponctuel isolé. L'approche DOE Phadke préconise d'utiliser des tableaux orthogonaux pour échantillonner suffisamment l'espace des paramètres pour toucher toutes les régions de défaut possibles.

Les failles isolées ne seront probablement pas identifiées, mais elles sont généralement moins nombreuses que les régions de failles.

L'approche DOE vous donne un moyen systématique de choisir les valeurs des paramètres à varier.

Ils peuvent être utiles pour garantir que votre code gère non seulement le chemin heureux, mais également les cas marginaux. Une fois que vous savez que votre code fonctionne avec des variables normales, paramétrez le cas de test et assurez-vous que les valeurs nulles et 0, les chaînes vides, les grands nombres, les chaînes longues, les caractères Unicode étranges, etc., fonctionnent également correctement.

Il existe au moins deux versions de tests paramétrés, au moins dans JUnit 4.8. Ce sont: des tests paramétrés ( @RunWith(Parameterized.class)) qui nécessitent une source de données, qui génère / lit des configurations de paramètres prédéfinies, et des théories ( @RunWith(Theories.class)) qui, étant donné un ou plusieurs ensembles d'entrées possibles par type d'argument, peuvent exercer la spécification de méthodes données. Cela ressemble plus ou moins à ceci:

• spécifiez quelques valeurs possibles ( @DataPoints) pour les arguments de chaîne (comme null, chaîne vide, chaîne non vide, chaîne très longue)
• spécifiez quelques valeurs possibles ( @DataPoints) pour les arguments de la classe Animal (comme null, Doginstance, Catinstance, Birdinstance)
• prepare @Theoryqui accepte un Stringparamètre et un Animalparamètre. il sera exécuté avec toutes les combinaisons possibles des valeurs de paramètres possibles (dans l'exemple donné, ce serait 4x4 = 16 combinaisons, y compris ( null, null))
• si la méthode en cours de test ne peut pas accepter une combinaison, utilisez Assume.assumeThatles importations statiques pour filtrer les combinaisons non valides (par exemple, lorsque vous voulez vérifier le comportement de la méthode pour les chaînes non vides, l'une des premières lignes serait "supposer que ce n'est pas nul")

Comme écrit précédemment - cela n'a aucun sens de tester toutes les combinaisons possibles de chaque méthode (cela explose les ensembles de tests, imaginez tester une méthode avec 5 paramètres, chacun n'ayant que 5 valeurs possibles: 5 ** 5 -> plus de 3000 tests !), mais pour les méthodes critiques (comme les méthodes API), je l'encourage, juste pour être prudent ...

Exemple générique:

• Méthodes avec des arguments de chaîne. Utilisez des tests paramétrés pour tester différentes entrées et leurs sorties attendues. Il est beaucoup plus pratique d'avoir une liste de paires (entrée, attendue) que d'écrire un TC pour chaque paire.

• Appliquer le même scénario sur différents arguments. Nous avons un scénario qui fonctionne avec l' Animalobjet et ont beaucoup de sous - classes telles que Dog, Cat, Bird. Créez une liste des animaux disponibles et testez le scénario sur eux.

Béton pour le webservice:

• À partir de l'exemple des arguments de chaîne ci-dessus. Testez ce qui se passe avec différents arguments du même type mais avec des valeurs différentes.

Les tests paramétrés fonctionnent bien pour tester des fonctions / fonctionnalités qui ont une entrée simple lorsque vous souhaitez tester une variété d'entrées.

Ils ne fonctionnent pas bien pour tester différentes fonctionnalités et entrées complexes. Ils ne doivent pas être utilisés comme structure de commodité pour écrire moins de code.

Un cas où j'utilise beaucoup de tests paramétrés de manière TDD est l'écriture d'analyseurs - je peux commencer avec une liste si entrée et sortie attendue, puis écrire le code afin qu'il passe tous les cas de test.

Mais j'ai vu quelques horreurs des tests paramétrés. Non, Virginie, votre suite de tests ne devrait pas avoir besoin de ses propres tests unitaires.