Cas de test pour 100% de couverture de branche sans erreur?

Question

L'énoncé du problème est

Une méthode qui a un zéro défaut que vous pouvez écrire une suite de test qui a une couverture de déclaration de 100% mais ne trouve pas la faute et une autre suite de tests qui a 100% de couverture de branche révèle la faute?

Voici la méthode que j'ai écrit pour la même

public faultyMethod1(int x, int y) { 
    int X =x; 
    int Y = y; 

    if (Y !=0){ 
    Z = X/Y; 
    } else { 
    System.out.println("Sorry. That's an DiviDeByZeroException"); 
    } 
} 

faultyMethod1 (1,2); 
faultyMethod1 (2,0); 

Le code ci-dessus pour obtenir suite de tests qui a 100% de couverture de branche qui ne révèle la faute »

Qu'en est-suite test qui a une couverture de déclaration de 100% mais ne trouve pas la faute?

Answer 1

Faisons un autre exemple ...

// The method, according to our imaginary specification, should do: 
// return x * y, IF x is less than 2 
// return x + y, in any other case 
public int doSomething(int x, int y) { 

if (x < 2) { 
    return x * x; // this is our bug, it SHOULD be x * y 
} 

return x + y; 

} 

Maintenant, imaginez que nous avons deux tests:

assertEquals(0, doSomething(0, 12)); // works, as 0 * 0 == 0 * 12 
assertEquals(20, doSomething(10, 10)); // works fine 

Donc, nous avons maintenant une couverture de test 100% (parce que x 2 < branche a été couvert, ainsi que l'autre). Mais nous n'avons pas trouvé le bug, puisque l'utilisation de zéro comme valeur pour x le cache (puisque 0 * quelque chose est toujours 0, y n'est pas pertinent). Nous aurions besoin de quelque chose comme ça ...

assertEquals(12, doSomething(1, 12)); // fails, because it will be 1*1 == 1 

Le même problème peut se produire pour toute autre situation, y compris une division par zéro. Je ne peux pas imaginer un bon exemple, mais je suppose que vous avez l'idée de base que d'avoir une couverture de 100% ne signifie pas trouver 100% de tous les bugs. (Un moyen cool de les trouver serait le test de mutation, mais c'est un sujet assez avancé.)

Answer 2

Que diriez-vous de confondre un ET logique avec un OU?

// This method must never throw; on error, it shall return -1. 
int foo(final String s, final int n) { 
    if (s != null || n != 0) { 
     return s.length()/n; 
    } else { 
     return -1; 
    } 
} 

Les entrées de test suivantes atteignent une couverture de 100% et ne dévoilent pas le bogue.

assert foo("everything is fine", 6) == 3; // happy path, ok 
assert foo(null, 0) == -1;     // error path, ok 

suite de test n'a pas de branche couverture foll, cependant, parce que les deux expressions ORED ensemble évaluent à la même valeur dans chaque cas. L'ajout des deux cas de test suivants complète la couverture de la branche et expose le bogue.

assert foo("bingo", 0) == -1; // ArithmeticException 
assert foo(null, 4) == -1;  // NullPointerException 

En fait, ces quatre entrées ensemble aussi parvenir à une couverture de chemin qui est une exigence encore plus forte que la couverture de la succursale.