Discussion :

[shaiHulud]

Bonjour,

J'ai un mécanisme de génération de classes (qui génère des fichiers source), et j'écris des tests unitaires sur ces classes générées :
- La méthode main() de la classe Generation génère un fichier source A.java
- J'ai une classe TestA de tests unitaires sur la classe A, qui a donc besoin de l'importer.

Mon but est que JUnit génère tout seul la classe A (en appelant Generation.main()) avant de lancer le moindre test.
Le problème est que testA a besoin d'importer A, donc:
- @BeforeClass ne marchera pas ici. Il faut que JUnit génère A avant de faire le moindre Compilation check sur testA.
- Si j'utilise un dynamic ClassLoader dans testA, je dois réecrire tout le test avec de l'introspection, plutôt qu'avec les méthodes déclarées dans la classe A, ce que je voudrais éviter.

Sauriez-vous comment faire ?

Merci d'avance !

[Pill_S]

Euh c'est ton test unitaire qui génère des sources? un peu bizarre ça...

En général, c'est une procédure séparée, lancée avant les tests, qui génère les sources.

En Maven par exemple, tu as la phase "generate-sources", exécutée bien avant les tests, qui produit des sources dans target/generated-sources. Ensuite, l'ensemble est compilé (sources+sources générées+tests), puis les tests sont exécutés.

Il faut bien dissocier 1) générer des sources puis 2) compiler puis 3) lancer les tests.

PS: Maven vaut vraiment la peine d'être étudié. Il découpe le cycle de vie d'un projet en phase distinctes et bien séparées, et tu n'aurais pas toutes ces questions à te poser si tu l'utilisais...

[shaiHulud]

Merci Pill_S !

J'utilise Maven, mais je me demandais si JUnit était assez grand pour traiter la question.
Apparement pas, et effectivement Maven semble donner une réponse "propre".

[tchize_]

Ouais enfin c'est bizarre qu'un unit test test une classe générée. Que le unit test teste le générator oui, mais la classe générée, non. C'est du test bullshit.

[shaiHulud]

Hello tchize_,

C'est du test bullshit

Je ne sus pas sur de comprendre pourquoi. Si le generateur ou le code générant évolue, tu peux vouloir tester que l'intégration de la classe générée se passe toujours bien.

[Pill_S]

Hello tchize_,

Je ne sus pas sur de comprendre pourquoi. Si le generateur ou le code générant évolue, tu peux vouloir tester que l'intégration de la classe générée se passe toujours bien.

Assez d'accord personnellement, mais je pense que ce que tchize_ veut dire, c'est qu'on ne test pas *directement* les objets générés. On teste les classes qui les utilisent (et du coup on couvre aussi les classes générées). De toute façon, souvent, 1) le code généré est trop simple pour mériter des tests personnalisés (c'est souvent que des beans, des adapters, etc.) et 2) on fait confiance au générateur

[tchize_]

Hello tchize_,

Je ne sus pas sur de comprendre pourquoi. Si le generateur ou le code générant évolue, tu peux vouloir tester que l'intégration de la classe générée se passe toujours bien.

Tu as trois choses à tester:

• un test d'intégration: étant plus loin que les unit test dans la chaine, normalement ta classe a été générée depuis longtemps ET c'est c'est l'ensemble de l'appli que tu teste pas ses composants. Pour ça, le unit test n'a même pas à savoir que la classe est générée. Je pourrais la créer à la main, la maintenir à la main ou la faire disparaitre, le unit test reste le même
• un test sur le générateur même: le générateur étant un outil à part, ça fait l'objet idéalement d'un projet séparé où le générateur est testé. Il n'y a pas de référence explicite aux classe générées, juste des références indirectes: "je prend la sortie du du GeneratorA et je regarder que cette sortie correspond à certains critères". Comme par exemple: est-ce qu'elle dispose d'une méthode X, est-ce qu'elle compile, etc.
• un test unitaire sur le code qui utilise le code généré: on lui substitue un mock puisqu'on teste l'appelant et pas la classe générée.

aucun de ces cas ne nécessite que tu génère la la fois la classe depuis le test et que tu dispose du byte code généré à la compilation du test unitaire