Discussion :

[alex2746]

Bonjour, je voudrais quelques conseils concernant des tests Junit.

Je dois tester un constructeur et une méthode toString() (qui a été réécrite). Voici la classe à tester.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public class Identite{
   private String nom;
   private String prenom;
 
   public Identite(String nom, String Prenom) throws MonException{
       if (nom.length()>20) 
          throw new MonException ("Le nom est trop long!");
       this.nom=nom;
       this.prenom=prenom;
   }
 
   public String toString(){
      return ("Le nom : " + nom + " ,le prénom : " + prenom);
   }
}

Pour les tests, voici ce que je pense faire, mais je ne sais pas trop quoi faire dans le cas d'une exception... Dois je faire des try and catch et est ce que les assertEquals du constructeurs doivent être dans les try ou en dehors?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
public class IdentiteTest extends TestCase{
   public void testConstructeur{...}
 
   public void testToString(){
      try{
        Identite monId = new Identite ("Louis","Jacques");
        assertEquals("Le nom :  Louis , le prénom : Jacques",monId.toString());
        }catch (MonException ex){
            System.out.println("Erreur du constructeur");            
        }
}

Merci d'avance!

[tchize_]

A moins que tu ne veuille tester explicitement l'exception dans ton test, le plus facile est de laisser l'exception remonter au delà de ton test. Ainsi JUnit sais que le test est en erreur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class IdentiteTest extends TestCase{
   public void testConstructeur{...}
 
   public void testToString() throws MonException{
 
        Identite monId = new Identite ("Louis","Jacques");
        assertEquals("Le nom :  Louis , le prénom : Jacques",monId.toString());
 
}

Au fait, normalemen, pour toString, tu ne devrais pas avoir de "MonEception", la signature de toString ne mentionnant pas cette exception.

[alex2746]

Merci pour la réponse. En effet le toString() ne procure pas d'exception, mais comme pour tester le toString() je dois créer un objet et que le constructeur procure une exception je dois la traiter dans le test du toString() (ou la laisser passer comme tu disais)... Je me trompe peut-être?

Merci d'avance.

[tchize_]

Si l'exception traverse toString(), c'est que c'est qu'elle descend de runtimeException. Tu n'a alors rien à faire de particulier pour qu'elle remonte automatiquement au delà de ton test, vers junit.

Là où tu pourrais avoir du travail particulier à faire, c'est si tu veux tester que ta méthode envoie bien une exception dans des conditions particulière. Dans ces cas là, j'utilise toujours le schema suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
try {
   unObjet.methodeQuiDoitLancerMachinException();
   fail("Un exception était attendue!");
} catch (MachinException e){
   // rien à faire, c'est normal.
}

[alex2746]

Merci

[philippe.bernard]

Pour le test d'exception, l'appel à fail est la formule consacrée. Cependant, à force de le faire, on peut oublier de l'appeler. Et là... on ne teste plus rien. Personnellement je préfère définir un helper accessible depuis les tests JUnit. En plus, par la magie de la complétion d'Eclipse & co, il y a moins de code à saisir.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public abstract class ExceptionTester extends TestCase {
  public abstract void runTestedAction() throws Throwable;
 
  public ExceptionTester(Class expectedClass) {
    try {
      runTestedAction();
    }
    catch (Throwable t) {
      assertEquals(expectedClass, t.getClass());
      return;
    }
    fail("Expected " + expectedClass + " but got no error");
  }
}

Puis, lorsqu'on a besoin de vérifier un lancement d'exception :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public void testFailingMethod() {
  new ExceptionTester(Exception.class) {
    @Override
    public void runTestedAction() throws Throwable {
      touchyMethod();
    }
  };
}

Bonne continuation,
Philippe

[tchize_]

Cette méthode est bien gentille mais fortement limitée dans ses cas d'utilisation. En général, on a une instance x d'un objet, sur lequel on effectue différents test. Avec une classe anonyme comme présenté dans ce code, la classe anonyme n'a pas accès au contexte de la méthode de test, a moins de déclarer les variable locale à la méthode comme étant statique, ce qui pose tout un tas d'autres problème.

quand a l'absence du fail, on le vois tout de suite car le test n'échoue pas lors du premier lancement (hors un bon test doit commencer par échouer, car il doit être fait avant que le code testé ne soit écrit)

[philippe.bernard]

Cette méthode est bien gentille mais fortement limitée dans ses cas d'utilisation. En général, on a une instance x d'un objet, sur lequel on effectue différents test. Avec une classe anonyme comme présenté dans ce code, la classe anonyme n'a pas accès au contexte de la méthode de test, a moins de déclarer les variable locale à la méthode comme étant statique, ce qui pose tout un tas d'autres problème.

Je ne suis pas sûr de comprendre. x doit être déclaré final, ce qui n'est pas toujours souhaitable en effet. Mais souvent c'est tout à fait acceptable.

quand a l'absence du fail, on le vois tout de suite car le test n'échoue pas lors du premier lancement (hors un bon test doit commencer par échouer, car il doit être fait avant que le code testé ne soit écrit)

Tout à fait.

Généralement je conduis prudemment. Ça ne m'empêche pas de mettre ma ceinture de sécurité.

[tchize_]

Je ne suis pas sûr de comprendre. x doit être déclaré final, ce qui n'est pas toujours souhaitable en effet. Mais souvent c'est tout à fait acceptable.

Je vais prendre un exemple simple, x est une valeur changée régulièrement dans une boucle, un final ne fait pas l'affaire, mais le test en a besoin, on pourrait en faire un champ plutot qu'une variable locale, mais là tu risque fortement les effets de bords.