Discussion :

[s-ehtp]

Bonjour Tout le Monde,
je suis en train de tester JUnit sous Eclipse .En fait pour chaque Classe on doit implémenter une une ClasseTest correspondante. Est ce pas une tache fastidieuse, si mon Projet est Grand?
j'aimerais Bien savoir s'il existe une manière plus efficace pour travailler avec JUnit
Merci!

[Pill_S]

pas que je sache...

par contre, il ne faut pas tester TOUTES les classes et TOUTES les méthodes. Il faut plutôt ne tester que le code qui n'est pas assez simple pour se débugger facilement. Typiquement, un module de calcul de coûts/marges/chiffre d'affaire etc., ça se teste. Un bean qui stocke des données et n'expose que des getters/setters, ça ne se teste pas...

[CastorJoyeux]

la manière de faire correctement du test unitaire c'est d'écrire le test avant d'écrire la classe correspondante (en réalité, tu fais des aller retour).

Non ce n'est pas une tâche fastidieuse, c'est assez rapide. Exemple: tu a besoin d'un classe tableur style excel...

Code :

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

1
2
 
Tableur = new Tableur();

Hop, tu crée la classe au passage (eclipse te propose même de créer les classe inexistantes automatiquement :p)
capable de stocker du texte et le retourner à une coordonée précise (cellule)

Code :

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

1
2
3
4
 
Tableur = new Tableur();
tableur.put(0,0,"test");
assertEquals("test",tableur.get(0,0));

(et hop, tu crée vite fait tes deux méthode, de mannière simple)

Code :

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

1
2
3
4
5
6
7
8
 
String texte;
public void put(int x, int y, String texte){
    this.texte=texte;  // on va y revenir ;)
}
public String get(int x, int y){
    return this.texte;  // on va y revenir ;)
}

Les cellules sont différenciées

Code :

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

1
2
3
4
5
6
7
8
9
10
 
  Tableur = new Tableur();
  tableur.put(0,0,"test1");
  tableur.put(69,12,"test2");
  tableur.put(80,1,"test3");
  tableur.put(12,18,"test4");
  assertEquals("test1",tableur.get(0,0));
  assertEquals("test2",tableur.get(69,12));
  assertEquals("test3",tableur.get(80,1));
  assertEquals("test4",tableur.get(12,18));

qui va foirer évidement, donc on corrige la classe:

Code :

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

1
2
3
4
5
6
7
8
 
Map<String,String> tableau = new HashMap<String,String>();
public void put(int x, int y, String texte){
    tableau.put(x+","+y,texte);  
}
 public String get(int x, int y){
      return tableau.get(x+","+y); 
 }

Le test et la classe évoluent en même temps et c'est le test qui sert de guide à la classe. Rien ne sert de faire un test après coup qui "confirme que la classe fonctionne comme elle est codée" car ça, c'est une évidence même, un test qui dirigie comment la classe doit être codée est beaucoup plus efficace à la fois en termes de temps de développement et en terme d'utilité, ainsi ton test confirme plutot "la classe fonctionne comme il a été demandé dans les specifications"!

Le principe du test unitaire étant donc
1) tu crée un test, qui foire (un test qui réussi n'apporte rien en termes de développement)
2) tu code / change ta classe pour que le test réussise
3) tu modifie le test pour rajouter des besoins et de manière à ce qu'il foire
4) retour au point 2 jusqu'à totalité des spécification.


Après il y a aussi les tests de régression. tu prend un bug rapporté, tu le reproduit dans un test, et tu modifie ensuite ta/tes classes jusqu'à ce que le test réussisse.


Autre conseils qu'on m'a appris:
ne jamais mettre plus de 5 minutes pour un aller retour. Si le nouveau test met plus de deux minutes à écrire, faut le couper. Si le code ajoutant la fonctionnalité met plus de 5 minutes à écrire, elle doit être scindée en éléments plus simples à tester

Last but not least: ne jamais quitter le bureau le soir avec un unittest qui réussi, toujours avoir une fonctionnalité prête à être codée le lendemain

[CastorJoyeux]

et je plussoie pill_s, un getter/setter n'est en général pas tester, on évite de tester l'évidence, mais attention à ne pas croire que trop de trucs sont évidents

[legentil]

Salut !
Pour ma part, j'utilise JUnit avec Eclipse et dans la théorie oui, il faut faire une classe par classe à tester.
Bien sûr, ça prend pas mal de temps à mettre en place si tu veux tout tester comme il faut (chaque chemin dans chaque méthode), moi du coup je trie un peu ce que je teste ou pas (En général moi je fais des tests très détaillés dans les classes de "bas niveau" pour être sûr de partir sur des bases fiables).
Il faut aussi bien les penser au début pour pouvoir les faire évoluer facilement, chaque fois que ton programme devra évoluer.

Par contre au final je m'y retrouve largement, que ce soit au niveau correction de bug ou évolution des fonctionnalités, ça permet de créer de nouveaux tests très rapidement, et en plus en assurant un minimum de non régression

à +!

[s-ehtp]

ça devient trés clair pour moin maintenant.
Merci pour vous tous !

[professeur shadoko]

et je plussoie pill_s, un getter/setter n'est en général pas tester, on évite de tester l'évidence, mais attention à ne pas croire que trop de trucs sont évidents

ben justement c'est là que le bât blesse dans beacuoup d'appli.
le rôle des accesseurs/mutateurs étant bien de vérifier un certain nombre de conditions qui restreignent le type de la propriété (style: entier oui mais positif!).
-bon perso j'utilise pas Junit et je fais mon propre truc, mais chut! ne l'ébruitez pas-
Ce qui amuse toujours les gens c'est le nombre incroyable de tests qu'on peut générer (plusieurs centaines à chaque fois): ça peut sembler idiot de tester par ex. un nombre positif petit, un nombre normal, divers nombres gros, etc.... (bien sûr comparer si set(x) et compatible avec get n'est pas ce qui nous fatigue le plus)
on se dit qu'on s'amuse à augmenter le nombre de tests juste pour pouvoir se vanter... mais le jour où on trouve des bugs insoupçonnés sur des cas limites là ça impressionne (et ça m'est arrivé!).

[Pill_S]

-bon perso j'utilise pas Junit et je fais mon propre truc, mais chut! ne l'ébruitez pas-

hum alors là je suis assez étonné! moi qui pensais que tu avais une culture du dév interdisant ce genre de chose, de part ton expérience et ta signature....

m'enfin pas grave l'important est d'avoir des tests reproductibles, pas de faire la publicité d'un framework x ou y

[professeur shadoko]

hum alors là je suis assez étonné! moi qui pensais que tu avais une culture du dév interdisant ce genre de chose, de part ton expérience et ta signature....

personne n'est parfait !
(pssst. chut! ne l'ébruitez pas mais je pense que JUnit ... euh non je n'ose pas ... pas taper! pas taper!)

[CastorJoyeux]

ben justement c'est là que le bât blesse dans beacuoup d'appli.
le rôle des accesseurs/mutateurs étant bien de vérifier un certain nombre de conditions qui restreignent le type de la propriété (style: entier oui mais positif!).

J'aurais du être plus précis: je ne teste pas les getters/setters simple qui sont autogénéré par l'ide. Certe si une propriété a des limites a respecter, alors oui je la test . Par expérience, 90% de mes getters setters sont simpel et sans logique, c'est juste un réflexe de programmation orientée objet (préférer les accesseurs aux champs publics)

Il est inutile et contre productif de tester çà:

Code :

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

1
2
public void setA(int a){this.a=a;}
public int getA(){return a;}

Par contre ceci devrait être testé

Code :

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

1
2
3
4
5
public void setA(int a){
    if (a<0) throw new InvalidArgumentException("a must be positive");
    this.a=a;
}
public int getA(){return a;}

on se dit qu'on s'amuse à augmenter le nombre de tests juste pour pouvoir se vanter... mais le jour où on trouve des bugs insoupçonnés sur des cas limites là ça impressionne (et ça m'est arrivé!).

Il faut aussi viser correctement le plan de test. Il est inutile, en général, de tester trois nombres positifs très grands, un seul suffit (Integer.MAX_VALUE typiquement ou Long.MAX_VALUE suivant les cas) ainsi que les cas limites de l'algorithme concerné. . L'idéal, en méthodologie agile en tout cas, c'est justement les aller -retour test - code où chaque nouveau test doit être en erreur. Ecrire un test qui réussi ne sert en général, paradoxalement, à rien . Il faut écrire un test qui rate, qu'on fait ensuite réussir