Discussion :

[sbrisard]

Bonjour,
j'aime beaucoup le framework JUnit, très pratique.
J'élabore en ce moment des tests qui, bien qu'ils soient assez simples, ne sont pas à mon avis unitaires : ils couplent plusieurs classes, et plusieurs méthodes dans chaque classe.
Existe-t-il des conventions pour de tels tests ? J'ai cru comprendre qu'il était recommandé d'éviter JUnit. Vaut-il mieux écrire un "vrai" programme de test Java, qui émet un rapport ? Si oui, existe-t-il des librairies pour créer des rapports de test simplement ? Puis-je encore utiliser les assertions définies dans JUnit ?
Merci d'avance pour vos réponses,
Sébastien

[dingoth]

Si tu veux vraiment faire du test purement unitaire, JUnit seul ne suffit pas. Puisqu'à un moment ou à un autre, tu dois faire tourner une bonne partie du programme. Des développeurs se sont aperçu de ces limites et ont développé des bibliothèques de ce qu'on appelle le "mocking". Actuellement en Java, il existe deux outils de ce genre principaux : JMock et EasyMock. Même si je sais ce que cela fait en théorie, je n'ai jamais utilisé ces deux outils en profondeur et ne pourrais en faire une comparaison.

Pour info, le mocking, c'est le fait de simuler un comportement avec des objets dummy, voir http://en.wikipedia.org/wiki/Mock_object.

[sbrisard]

En fait, je crois que je sors très largement du cadre des tests unitaires. En effet, je teste par exemple plusieurs implémentations de plusieurs méthodes permettant d'effectuer le même calcul. Mon test consiste alors à vérifier que les différentes méthodes donnent le même résultat (pas question de *simuler* le comportement d'un objet, il me faut son comportement réel...).
Les tests sont donc beaucoup plus élaborés, mais par contre, j'ai l'impression de réinventer la roue à chaque fois que je veux écrire un tel test. Je me demandais si des gens avaient réfléchi à une architecture commune pour de tels tests "étendus".
Merci d'avance !!!
S

[tchize_]

Il faut pas te concentrer comme ça sur le mot "unitaire" de test unitaire. Une unité n'est pas nécessairement un module de l'application. vois plutot une unité comme un comportement de ton application. Par exemple, dans ton cas, trois modules de calculs codés différement doivent te fournir le même résultat. Ca c'est bien une unité de test, que tu pourrais appeler, par exemple "TestModulesHaveSameResults". Il arrive souvent que pour une batterie de tests, tu as besoin de faitre toujours la même initalisation. DAsn ce cas, ce que je fait personnellement, je crée une abstract class, qui étends TestCase et qui fait toujours plus ou moins la meme initialisation dans le setup. Eventuellement je passe des argument à setup (comme quand par exemple il faut pouvoir spécifier un fichier de config différent pour certains tests). J'y met souvent aussi quelques méthodes permettant de créer des choses basique. Exemple un tst abstrait pour des classes hibernante, j'y mettrais par exemple quelque méthode genre "createVehicule(brand,year)" qui me permettent de ne pas dupliquer partout du code créant des véhicule à chauqe fois que j'en ai besoin

Bref, on applique dans les tests unitaire les même regle de récupération de code et de hierarchie de classes qu'on applique dans le code principal. (Souvent on est assez laxiste pour aller plus vite :p)

[sbrisard]

Merci pour cette réponse !
J'en reste donc à utiliser JUnit, même si mes tests deviennent assez compliqués, et surtout s'ils "croisent" plusieurs classes.
Sébastien

[dingoth]

Je crois que je me suis mal exprimé.

Le mocking ne consiste pas en la simulation d'objets à tester, mais en la simulation d'objets dont dépend l'objet à tester.

Donc en gros, on a A qui doit être testée, A contient B et C. Nous simulerons le comportement de B et de C tels qu'ils doivent être utilisés par A.