Cet article est un extrait du livre sur JUnit

La couverture de code est une mesure qui permet d’identifier la proportion du code testé. Les outils de couverture permettent de réaliser cette mesure, d’identifier les parties de code non couvertes et de les visualiser.

Cette mesure peut être calculée de différentes manières. Pour illustrer ces différents modes de calculs, nous utiliserons le code suivant :

public class CompteBancaire {
  protected String numeroDeCompte;

  public CompteBancaire(String numeroDeCompte) {
   this.numeroDeCompte = numeroDeCompte;
  }

  public String interrogerCompte(String motdepasse) {
    String resultat = null;
    if (motdepasse.equals("madatedenaissance")) {
      Integer solde = calculDuSolde();
      resultat = "Information du compte:";
      resultat += numeroDeCompte;
      resultat += ".\r\n";
      resultat += "Votre compte est créditeur de ";
      resultat += solde.toString();
      resultat += "€";
    } else {
      gererErreurDeMotDePasse();
    }
    return resultat;
  }

  protected Integer calculDuSolde() {
    Integer solde = new Integer(0);
    solde = 1000;
    solde += 100;
    solde -= 200;
    solde += 400;
    solde -= 300;
    return solde;
  }
  protected void gererErreurDeMotDePasse() {
    throw new RuntimeException("Erreur non gérée correctement");
  }
}

Nous testerons cette classe à l’aide du test suivant :

public class CompteBancaireTest {
  @Test
  public void testInterrogerCompte() {
    CompteBancaire compte = new CompteBancaire("0123456789");
    String verif = "Information du compte:0123456789.\r\n";
    verifi += "Votre compte est créditeur de 1000€";
    assertEquals(
          verif,
          compte.interrogerCompte("madatedenaissance"));
  }
}

La classe testée contient 20 lignes de code exécutables, 4 méthodes et une condition, soit 2 chemins logiques possibles.

Nous pouvons alors calculer différentes métriques de couverture.

Couverture linéaire

La couverture en lignes de code indique la proportion des lignes de code exercées lors du test. Elle est la plus répandue et la plus simple à visualiser : chaque ligne compte pour un élément. Dans cet exemple, 18 lignes sur 20 sont couvertes. La couverture en lignes sera donc de 18/20=90 %.

La couverture en méthodes calcule la proportion des méthodes couvertes au moins une fois. Chaque méthode compte pour un. Ainsi dans notre exemple, sur les 4 méthodes présentes, 3 sont testées. La couverture sera donc de 75 %. Cette mesure ressemble à la précédente avec une granularité plus large.

Couverture conditionnelle

La couverture conditionnelle calcule la proportion des chemins logiques couverts. C’est la mesure la plus compliquée à appréhender car elle change notre vision du code : au lieu d’en avoir une vision linéaire sous forme de listing, elle pousse vers une vision arborescente du code. Chaque condition compte pour deux. Pour couvrir la condition à 100 %, il faut tester le cas où la condition est vraie puis celui où elle est fausse. Ainsi dans le cas d’une structure conditionnelle if/then/else, couvrir chaque branche compte pour un. Dans notre exemple, seul le cas then est couvert. La couverture de la classe est donc de 50 %.

Quelle mesure utiliser ?

La couverture en lignes de code est intéressante car très simple à appréhender. De plus, elle permet de facilement mettre en évidence les portions de code non testées par blocs.

Dans notre exemple, on peut constater que le cas d’erreur n’est pas du tout testé.

Cependant, il est facile d’être leurré par les chiffres remontés : en effet, les cas d’exécution normale (quand tout va bien) sont souvent ceux qui ont le plus de poids. Les cas d’erreurs sont en général bien plus légers. Ainsi, un code couvert à 90 % peut donner un faux sentiment de sécurité lorsque seul le cas nominal est testé.

C’est ce qu’illustre notre exemple : la gestion du cas d’erreur lève une exception système.

Il est même possible d’être complètement floué par cette mesure. Considérons le code suivant :

public class Secret {
  public String donnerSecret(String motdepasse) {
    String secret = null;
    if (motdepasse.equals("aliens")) {
      secret = " La vérité est ailleurs ";
    }
    return secret.trim();
  }
}
Testons cette classe à l'aide du test suivant :

public class SecretTest {
  @Test
  public void testDonnerSecret () {
    Secret message = new Secret();
    String verification = "La vérité est ailleurs";
    assertEquals(verification,
    message.donnerSecret("aliens"));
  }
}

Ce test couvre à 100 % le code autant en ligne de code qu’en procédure.

Pourtant, un bug critique se cache manifestement dans le code… En effet, l’exécution du programme suivant fait planter l’application :

public class ApplicationConsole {
  public static void main(String[] args) {
    Secret messager = new Secret();
    String message = messager.donnerSecret("motdepasseoublie");
    System.out.println(message);
  }
}

Exception in thread "main" java.lang.NullPointerException
              at Secret.donnerSecret(Secret.java:8)
              at ApplicationConsole.main(ApplicationConsole.java:4)

Ainsi, la couverture en ligne de code ne suffit pas pour donner une vision satisfaisante de la qualité intrinsèque du code.

La couverture conditionnelle est intéressante car elle donne une autre vision du code, en chemins d’exécutions possibles. Elle pondère différemment les proportions testées en partant du principe que chaque chemin a le même poids, indépendamment de sa longueur. Cependant, cette mesure ne permet pas d’apprécier la proportion de code testée. Ainsi, un code ne contenant que peu de chemins logiques, tous couverts, peut donner une fausse impression de sécurité. C’est pourquoi il faut balancer cette mesure avec une mesure en lignes de code ou en méthodes.

Ainsi, la mesure de la couverture de code sera une combinaison de différents modes de calcul. Chaque outil a son propre mode de calcul offrant le choix aux développeurs.

Cet article est un extrait du livre sur JUnit