Tests Junit avec exceptions

Version imprimable

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:

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:

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!

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:

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.

19/10/2008, 15h01
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.
19/10/2008, 19h57
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:

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

Merci ;)

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:

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:

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

07/06/2010, 00h10
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)
07/06/2010, 22h26
philippe.bernard

Citation:

Envoyé par 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.

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.

Citation:

Envoyé par tchize_

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é.
07/06/2010, 22h41
tchize_

Citation:

Envoyé par philippe.bernard

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.