Discussion :

[hibour]

Si t'as beaucoup de temps, je pense que une façon de faire serai d'utiliser JavaCC pour créer un parseur qui te permettera d'analyser le corps de tes méthodes et voir quels sont les attributs modifiés.
Tu pourras probablement trouver beaucoup de parseurs et grammaire existants pour Java mais tu dois les adapter pour ton besoin.
Ensuite tu pourras combiner l'utilisation de la réflexion et ton parseur pour trouver ce que tu veux.

Bon la parler c'est facile, je ne suis pas expert dans ce domaine mais je suis sure que ca se fais avec ca (peut être après que tu aies lu un livre sur les compilateurs ).

Je pense qu'on parlede trouver ca au runtime et dans ce cas on n'a pas les sources -> ton javacc est inutilisable mais il faut analyser le bytecode.

[unknow0]

bonjour,

après pour analyser le bytecode tu a des outil pas mal comme ASM.
mais bon tous ca reste quand même pas mal complexe ..

[hibour]

Alors quelqu'un a une solution ?
thelvin: arrête de philosopher

[Nehmé]

Je pense qu'on parlede trouver ca au runtime et dans ce cas on n'a pas les sources -> ton javacc est inutilisable mais il faut analyser le bytecode.

Si c'est pour faire un plugin Eclipse, le code source est accessible.
Il y a une API qui s'appelle JDT:
http://help.eclipse.org/galileo/inde...w-summary.html
très utile pour analyser le code java. (Merci à yann2 de me l'avoir montré)

[unknow0]

Alors quelqu'un a une solution ?
thelvin: arrête de philosopher

voila la solution:

Aucune chance... il faudrait analyser le bytecode de la méthode en question pour voir si (sous certaines conditions) elles peuvent faire muter l'objet.

:p

[Deaf]

De nombreux cas me semblent impossible à analyser, ne serait-ce qu'à cause de l'héritage.

Tu analyse une méthode toto qui appelle une méthode machin qui ne fait aucune modification.
Tu vas donc conclure que toto ne fait aucune modif non plus.

Manque de bol, dans une classe fille, la méthode machin est redéfinie et modifie l'état. Donc toto n'est plus "clean" dans cette classe fille.

A mon avis, tu pourras ne tirer de conclusions qu'avec des contraintes très strictes (pas d'appels à des méthodes non final ou non private).

[unknow0]

oO je ne vois pas le problème il faut de toute manière analyser chaque méthode pour toute les classes (hériter ou pas) et tirer des conclusion pour chaque class a pars
ainsi la méthode toto sera clean dans la class mère est non-clean dans la class fille indépendamment l'une de l'autre.

[Rei Ichido]

Aucune chance... il faudrait analyser le bytecode de la méthode en question pour voir si (sous certaines conditions) elles peuvent faire muter l'objet.

Mais théoriquement, toutes les méthodes qui ne renvoient pas de résultat font muter un objet. Car une méthode qui ne fait pas muter l'objet ni ne renvoie de résultat ne fait rien!

La question étant de savoir si on fait muter l'objet sur lequel s'applique la méthode, c'est plutôt faux, ça peut modifier l'état d'un autre objet, ou faire du log par exemple.

[Pill_S]

La question étant de savoir si on fait muter l'objet sur lequel s'applique la méthode, c'est plutôt faux, ça peut modifier l'état d'un autre objet, ou faire du log par exemple.

faire muter l'object courant c'est faire muter une de ses propriétés... après, la mutation peut être directe (affectation d'un champ) ou indirecte, mais ça reste une mutation...

de toute façon c'est un faux débat, car le but étant de lister les méthodes qu'on doit tester car elles peuvent potentiellement changer l'état d'un objet, c'est pas vraiment exploitable dans le monde réel. Une méthode doit être testée si le code qu'elle contient est suffisament complexe pour risquer d'être incorrect (not "too simple to fail"). Enfin bon j'ai peut-être mal compris le but de ce post, mais perso je n'y vois aucun intérêt...

[hibour]

Je pense que la question posée est pertinente, son cas d'utilisation pour les tests est un peu absurde car le programmeur sait ce qui doit être testé ou non, mais on pourrai avoir besoin d'une tel opération pour savoir si une méthode est threadsafe par exemple (si on ne modifie aucune propriété par une méthode alors pas de risque de problème d'exclusion mutuelle)