Je rencontre un problème lors de la conception de tests unitaires boîte noire sans redondance.Stratégie de tests unitaires: redondance à l'aide de la boîte noire
Voici un exemple:
class A {
Float function operationA(int: aNumber){
if(aNumber > 0){
return aNumber * 10 + 5.2;
}
else if (aNumber < 0) {
return aNumber * 7 - 5.2;
}
else {
return aNumber * 78 + 9.3;
}
}
}
class B {
boolean status = true;
Float function opearationB(int: theNumber){
if(status == true){
return a.operationA(aNumber);
}
}
}
Afin de tester correctement A.operationA(), je dois écrire au moins trois tests unitaires (aNumber
= 0, aNumber
> 0 et 0) < aNumber
.
Maintenant, disons que je veux tester B.functionB, en utilisant la stratégie de boîte noire, dois-je réécrire les trois tests unitaires similaires (theNumber
= 0, theNumber
> 0 et theNumber
< 0)? Dans ce cas, je devrais créer beaucoup de tests chaque fois que j'utilise la méthode A.operationA ...
Pourquoi y a-t-il un test de boîte noire? – dm03514
Les tests pour la «classe A» seraient suffisants. 'class A' est une dépendance de la classe B. lors du test de B, la classe A pourrait être mockée/truquée afin de tester uniquement la fonctionnalité supplémentaire de B. Pas besoin de retester la fonctionnalité ce qui a déjà été couvert. – Nkosi
@ dm03514 L'utilisation de la stratégie de boîte noire dans ce cas permettrait aux tests unitaires d'échouer lorsque l'opérationA est modifiée et renvoie un résultat qui change le résultat de l'opérationB. Cela n'a pas pu être réalisé en vérifiant simplement que l'opération A a été appelée dans l'opération B (stratégie de boîte blanche). –