2017-01-19 1 views
2

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 ...

+0

Pourquoi y a-t-il un test de boîte noire? – dm03514

+0

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

+0

@ 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). –

Répondre

2

Si la contrainte de boîte noire peut être desserrée, vous pouvez supprimer toute la duplication. J'aime vraiment les définitions de Jay Fields des tests unitaires solitaires vs sociables, explained here.

Il devrait être trivial de tester la classe A en isolation. Il n'a aucun effet secondaire et aucun collaborateur. Idéalement, la classe B pourrait également être testée isolément (solitaire) là où son collaborateur, classe a, est écrasée. Cela permet non seulement d'isoler la classe B, mais aussi de contrôler les défaillances en cascade. Si la classe B est testée avec la vraie classe vie A quand la classe A change cela pourrait provoquer une défaillance dans la classe B.

À une certaine collaboration point (sociable) devrait probablement vérifier, une façon de couple peut être:

  • un seul test socialable qui appelle b grâce à son interface publique et déclenche le cas par défaut dans la classe a
  • tests de niveau supérieur qui exercent une histoire d'utilisateur spécifique ou un chemin d'écoulement externe, ce qui déclenche la classe b

didn Désolé ne réponds pas à tes désirs question ct.