Reprise du message précédent :
  woh le clash

Bah non, c'est pas trop élite-compliant comme code

 
Et l'élite, elle pense quoi des tests EJB3    
 

bah nan
mais une discussion c'est pas statique, en général ça évolue
et on arrive à dire comment nous on procède sur notre projet tout beau avec des winners
j'ai déjà eu un projet ou on mettait les requettes dans des fichiers properties, mais là avec sa lubbie du nom de colonne qui pourrait potentiellement changer alors que jamais un nom de colonne n'a changé depuis que l'appli existe ça lui plairait pas.
donc ouais je me plains, et j'assume le fait d'emmerder real moins moins

ben euh, tu demandais pour les mocks, je dirais easymock ou mockito (n'ait pas encore utilisé ce dernier); mais je ne suis pas de saisir le rapport avec ejb3.

je vous emmerde une dernière fois avec mes "worst of elite", c'est le bouquet final, elle a fait un id de clef primaire de table, basé sur un bigint étant la date exprimée en millisecondes. Une séquence en millisecondes quoi.
Y a plus qu'a croiser les doigts pour que deux utilisateurs cliquent pas en même temps, c'est quand même très grand une milliseconde à l'échelle informatique non ?

 
 
D'une manière générale, je demande des retours / best practices sur les tests en environnement J2EE (dans mon cas EJB3 + JBoss), les mocks font partie du lot. J'utilise naïvement JUnit4 En Java standard, donc d'emblée je me tournerais vers la même chose + JUnitEE. Mais c'est peut-être pas le meilleur choix, d'où interrogation, post sur le topic experts, profits.

ben s't'à dire que sans cas concret (i.e quel objet tu veux tester), c'est pas évident de repondre...  je suis pas convaincu que junitee ait encore un sens avec ces technos

On va dire que je suis dans le cadre d'un projet qui débute, donc mettre en place une politique de tests. Dans l'idée, je pense pas que je vais m'amuser à couvrir la partie de persistance, mais la logique métier elle le serait.
 
Donc partons sur du SessionBean.
 
Maintenant clairement, si vous voulez me parler de la logique de test dans votre cas, ce que vous utilisez, ce que vous couvrez, la manière dont vous le faite et si la lumière rouge lâche en plus les chiens, faites vous plaisir  

je te suggère de commencer petit : 2 bean qui jouent au ping pong les, tests qui vont avec, puis quand t'atteins les limites de ton outil de test, t'en cherche un autre etc.
 
Parce que les conneries du style : "on va en avoir besoin plus tard", j'pense que les compressions de budget de 2009 et leurs conséquences en sont le fossoyeur. On développe pour maintenant, on vise pour demain sans fermer aucune porte pour après demain, mais on tire pas des plans sur la comète.

OK. Finalement, je me retrouve avec JUnit et baste en somme.
 
Au moins, la transition sera pas trop dure...

ben, après faut faire la distinction entre tests unitaires (junit, easymock), et des tests d'integration dont tu peux avoir besoin aussi. Ceux-là sont souvent, au debut, réalisés par des humains.. selon l'experience de l'équipe et le projet lui-même, on y pense déjà... ou pas...
 
 

OK, merci les hommes  

et une base de données de test avec des info que l'on sait avec certitude être classes. On lance les tests de la couche de persistance sur cette base, on insère, on met à jour, on sélectionne, on efface, on vérifie tout ça, et on nettoie le caca qu'on vient de faire.

non ?
(parce que là en fait on part sur cette solution. Et donc, c'est bien du jUnit à la con)

euh dbunit ?

on dirait bien oui.
 
merci

question cobertura : c'est possible de lui dire d'ignorer les getters / setters simples, tout en vérifiant les méthodes getXXX de plusieurs lignes ?

<chieur-qui-répond-à-côté-de-la-question>nomme tes méthodes correctement </chieur-qui-répond-à-côté-de-la-question>

le client de l'interface n'a pas a savoir que le getter ne correspond pas a un bête attribut.

eh merde

même annoter mon getter, ca m'irait aussi, si y'a un truc tout fait.

c'est quoi le but, d'avoir le 100% magique de coverage ?

non mais d'avoir des chiffres un peu cohérent, ou de pouvoir voir un progrès au fil du temps (parce que sans ça, ajouter une classes / des attributs va pourrir son coverage; ou bien le coverage des get* magiks n'est pas compté)

mouais ok, je suis pas convaincu, mais ok

sinon apparement y a un mec qui a fait un patch de cobertura pour ca: http://sourceforge.net/tracker/ind [...] tid=720017
tu peux te builder un cobertura custom stu veux

nan, mais quand je n'ai pas 100%, je regarde ce qui n'est pas couvert par les tests, et c'est un peu pénible de passer sur une classe pour voir qu'il n'y a qu'un getter (ou pire, le constructeur par défaut) qui n'est pas testé. Ne pas prendre en compte ces trucs m'éviterai de passer sur ces classes. Mais bon, je ne vais pas aller jusqu'a me builder un truc custom, puis l'integrer dans maven et tout le bordel, surtout que c'est pour un projet perso.

chuis assez d'accord avec lorill, essayer de se ramener dans un monde binaire est plutôt bien : c'est couvert/c'est pas couvert, warning/pas warning etc.
et noter les quand on décide volontairement de ne pas couvrir un méthode ou de ne pas tenir compte d'un warning.

jpense que le point de souk, c'était de rappeler qu'un coverage de 100% n'est pas un but en soit (c'est juste un vague indicateur - à mon sens il n'est bon qu'a servir de barre qu'on ne peut voire que monter). maintenant qu'on a vu que c'était pas le but de lorill, tout le monde est content

bon alors les modos

I sont en WE prolongé

Vous permettez oui ?

ben nan

je passe sur hfr une fois tous les 4 jours, ça devrait laisser pas mal de temps pour un mass-delete d'un pauvre spam nan?

1h pour intervenir un dimanche soir, 'spèce de râleur.

au prix où on te paye et il te faut encore 1h

 
Mais pourquoi le monde est méchant avec moi ?

parce que tu postes dans le mauvais topic

Ça ne prend pas Émile

Et pourquoi est-ce que tu as retiré cette majuscule ?

Parce que j'avais copié de tête et en vérifiant j'ai vu qu'il y avait des erreurs

vous savez s'il y a moyen d'intercepter les accès en écriture à un champ en java ? avec CGLIB par exemple ?
 
l'idée c'est que j'ai une classe avec une tonne de champs qui est remplie par un formulaire, donc j'aimerai dégager les getters et setters pour gagner des lignes.
 
Comme je suis en swing, j'ai besoin d'observateur sur les champs pour le MVC. Pour pas trop me faire chier, j'ai fait un proxy et j'intercepte les setter pour balourder les évènements de propertychange.
 
J'aimerai passer une vitesse supérieure et dégager les getters et setters, mais j'ai quand même besoin d'envoyer les events. D'où ma question.