Joseph Morgan a déjà évoqué en détail l'idée des tests unitaires dans JMP. Quelques excellentes lectures :
Pour simplifier les choses dans ce blog, j'utilise la terminologie de Whittaker (2000) pour définir les tests unitaires.
Tests unitaires : domaine d'entrée
Le terme « test unitaire » désigne le test de composants logiciels individuels ou d'un ensemble de composants. Les testeurs définissent le domaine d'entrée des unités en question et ignorent le reste du système.
Concentrons-nous sur la deuxième partie, où les testeurs définissent le domaine d'entrée. Que se passe-t-il si nous avons une fonction que nous voulons tester, mais que nous voulons traiter les arguments individuels comme des unités ?
Prenons par exemple la fonction Beta Distribution de JSL (capture d'écran de l'index de script). La fonction Beta Distribution est utilisée pour modéliser des variables aléatoires comprises entre 0 et 1, souvent utilisées dans les statistiques bayésiennes.
Nous pourrions fixer alpha et bêta à quelque chose comme 0,5 et tester un certain nombre de valeurs différentes de q.
alpha = 0.5;
beta = 0.5;
Beta Distribution( 0.5, alpha, beta );
Beta Distribution( -1, alpha, beta );
Beta Distribution( 0, alpha, beta );
Maintenant, déterminer ce que nous attendons pour chaque appel de fonction à la fonction de distribution bêta est un article de blog à part entière (connu sous le nom de problème de l'oracle). Cependant, en supposant que nous sachions ce que nous attendons (dans ce cas, 0,5, une valeur manquante et 0), nous pouvons tester q. Chacune des entrées peut être vérifiée de la même manière individuellement de cette manière, comme alpha, bêta et même thêta et sigma.
Tests à un facteur à la fois (OFAT)
Que signifie se concentrer sur un seul argument à la fois ? En définissant les autres arguments sur une valeur fixe (comme la valeur par défaut) et en modifiant la valeur d'un argument, on s'approche d'un test via OFAT.
Lorsque nous sommes initiés aux expériences planifiées (typiques), nous discutons des pièges de l'OFAT. En particulier, l'OFAT est déconseillé en raison de l'inefficacité des ressources et des interactions manquantes. Nous pouvons voir que cette approche des tests présente les mêmes problèmes. Cependant, si nous testons des logiciels, nous pouvons réutiliser ces cas de test plus tard, donc la création de ces tests et la détermination des résultats attendus ne sont pas nécessairement un gaspillage de ressources de test. Si nous trouvons un problème (c'est-à-dire que le résultat n'est pas celui attendu), nous savons quelle entrée a été modifiée et a causé le problème. Cela est particulièrement utile si cela est fait dans le cadre d'un processus de développement d'application, où ces tests peuvent être exécutés régulièrement (là encore, un sujet pour un futur blog).
Où allons-nous à partir d’ici ?
Si vous avez lu ce blog et que vous vous êtes demandé pourquoi nous ne modifierions pas plus d'une entrée à la fois, rassurez-vous, nous le ferons. En fait, les prochains blogs aborderont la manière de traiter ce défi de test comme un problème de conception d'expériences. Restez à l'écoute !
Whittaker, JA, 2000. Qu'est-ce que le test logiciel ? Et pourquoi est-ce si difficile ? IEEE software , 17 (1), pp.70-79.
