Reprise du message précédent :
yeah, je suis maintenant une connection de 1st degree avec l'élite...

Après "j'ai la modération en MP", voici "j'ai l'élite en linkedIn"

c'st sympa de la part de ton ancien boss de t'avoir fait une recommandation

Edit : je m'excuse bien de demander pardon, mais prems et split...
IWHP200

prem's

deuz

J'invoque

Uhm, pour stubber une méthode statique, je l'ai dans le cul ou pas avec EasyMock ? je vois pas trop comment faire...

STATIC METHODS ARE T3H EVUL888

  C'est pas moi qui l'ai fait

svn blame  

et ensuite...
CALOTTE SUR SA BOUCHE888

oui, 'fin, il a mini 10ans d'XP, j'ai maxi 1mois d'XP pro.  

mouais, physiquement, il est balaise ? sinon il te reste à lui expliquer la testabilité ...

oui, surtout par rapport a moi en fait

oui mais bon bref.
 
 
 
 
 
 

oui tu l'as dans le cul.
on écrit pas les tests pour les autres, ça avance a rien a part perdre son temps parce que s'ils testent pas leurs propres merdes ils changeront jamais leur style intestable ("bah oui je teste, je lance l'appli et je vois si ça marche" )

La méthode fait juste un cast sur un objet venant d'acegi (je crois, hein, et ce truc est fourni aussi via une méthode statique) en me retournant un bel objet formé "jesaispascomment" et j'aurais bien aimé un mock a la place, histoire d'être sûr que ma partie-a-moi elle marche.
 
   Du coup, tous mes tests y pête (a cause d'acegi), soit je mock ce truc en moins de 5min, soit ça va finir par ** je cache mes tests **

et le code que tu testes appelle cette methode statique? ce que je fais des fois pour feinter c'est que j'override localement et anonynement une methode de l'objet sous test, pour contourner ce genre de conneries ::

cad ? j'ai pas compris  

Mon code resemble à ça :

public MonUser getMonUser() {
         AcegiUser acegiUser = ClassPasAmoi.getUserFromEvilStaticMethod();
         return monUserDAOaMoi.find(acegiUser.getId());
}

(l'appel peut être déporté dans une méthode bien sûr) sachant que cette méthode est dans une class dont hérite une tripoté d'autre class (et ce sont elles surtout qui sont testés)

tu deportes ClassPasAmoi.getUserFromEvilStaticMethod(); dans une nouvelle methode (package si tu veux)protected que tu nommes pqr ex. getAcegiUser()
 
puis:
 
public class PouetTest {
  public void testMachin() {
      // ...
      final AcegiUser acegiUserMock = createStrictMock(AcegiUser.class);
      // ...
      final Pouet p = new Pouet() {
         protected getAcegiUser() {
             return acegiUserMock;
         }  
     }
  }
}

c'est pas propre vu que tu modifies le code testé, mais tant que tes collegues sont pqs convaincus ou que vous n'avez pqs le temps de revoir le code de ClassPasAmoi, t'as pas le choix

Genre il est à ta droite?  

 
Chez nous, on n'a pas le droit d'ecrire nos propres tests, ce sont justement les autres qui doivent les ecrire, pour etre sur qu'on ne sera pas influence par notre code en ecrivant les tests.

Resalut,
 
Je cherche toujours un profiler (c'était un peu standby) qui permet de choisir exactement sur quelles methodes le profiler doit comptabiliser des statistiques sur les objets allouées, et nottament les méthodes appellées par celle ci.
En fait je me demande si il existe un outil qui permete de choisir sur quoi il s'active, par exemple configurable avec un fichier xml un peu comme log4j et son activation de log par package, mais sans avoir a modifier le code, et aussi qu'il ne s'agisse pas d'un simple filtrage de la sortie de trace.
 
En fait j'ai pas trop le temps de tous les tester, c'est juste que là certains veulent partir sur un traçage à la main avec positionnement de timestamp à l'aide de log4j a l'entrée et à la sortie de méthodes pour voir les temps de réponse et l'utilisation mémoire, mais je suis pas convaincu que ça soit le plus simple, sauf en l'état actuel de nos connaissance en matiere de profiling bien sur

il me semble que TPTP (intégré à Eclipse) sait faire ça correctement... A voir dans la présentation du produit. C'est sûrement pas le plus ergonomique/rapide, mais c'est gratuit.

Sinon dans les payants, JProfiler fait cela tres simplement.

YourKit > JProfiler, si il faut en choisir un des deux.

Tu peux argumenter un peu plus? Ca pourrait m'interesser.

D'après mon expérience (de tenter de profiler des JSPs servies via tomcat ), ils sont aussi lourds l'un que l'autre mais (en tout cas sous windows) YourKit est plus facile à intégrer (à tomcat toussa), "voit" plus de trucs et est globalement plus clair et plus simple que jprofiler.

Après j'en ai pas non plus fait une utilisation monstrueuse et je suis spécialiste ni de YourKit ni de JProf mais j'ai beaucoup moins souffert à mettre en place YK et à en obtenir des infos un minimum intéressantes

(de toute façon les deux sont dispos en full pendant 15j, donc je conseille de les tester, mais je préfère de très loin YK pour le moment)

Ca bastonne. Bon par contre, j'ai du en faire des vrai class, car je passe par le système de mock de Strypes qui se chie un peu dessus avec les class...

ça commence bien.
Ce que je veux dire, c'est que c'est débile de prendre son petit junior par la laisse et de lui faire écrire des tests pour ton code merdique (et donc de continuer a avoir du code de prod merdique, et de perdre le temps du gamin qui n'apprend rien à part que "écrire les tests c'est un boulot chiant" )

import static org.easymock.classextension.EasyMock.*;
 
 
(pourquoi je connais ça par coeur )

ça c'est du test de recette, rien à voir.

 
Euh non, ca n'a rien a voir. On fait autant de test que les autres, juste que l'on ecrit pas les tests pour ce que l'ont developpe.
 

 
Mais encore? Quelque soit les tests qui sont effectues chez nous, que ce soit des unit test, use cases, uat, ou autre conneries, c'est jamais la personne qui developpe qui realise le test. Au mieux elle peut le lancer dans le cadre des tests automatisables.

les tests U c'est à celui qui développe de les écrire, c'est lui qui connait le code.

Justement, c'est pour ca que ce n'est pas a lui de les ecrire. Il doit juste fournir l'interface et les resultats attendus. Au testeur d'etre le plus retors possible. Autrement, tu te retrouves avec des codeurs parresseux qui ne tests que des cas positifs en omettant les cas negatifs ou les cas non precises dans la spec.

On vit pas dans le même monde manifestement.
 
Dans mon monde, on fait confiance à ses équipes, la spec n'est pas vérifée par des tests U et une ambigüité est levée par la discussion.

Effectivement, on ne vit pas dans le meme monde...
 
Dans mon monde, on se connait au sein de notre petite equipe. Et c'est justement parce que l'on se connait que l'on sait que tout le monde n'est pas sensible aux aspects au sein du code. On sait que la spec va changer 3 fois dans les 15 jours qui viennent, parce que le client est pire qu'une girouette en pleine tornade. Du coup, au plus on est a travailler (et donc tester sur une meme fonctionnalite), au plus on est sur de pouvoir prendre le relais en cas d'un pepin (maladie, autre affectation, conge) et au plus on est sur que chacun a bien compris la spec de la meme maniere, car si le test foire, c'est soit que l'un des deux codeurs a merde (et donc enrichissement mutuel), soit que la spec contient une part de flou qu'il convient d'eclaircir.
 
Si tu rajoutes a cela le fait que l'on doivent travailler avec une equipe aux US 10 fois plus importante en terme d'effectif mais 2 fois moins performante, j'estime que ce sont des raisons suffisantes pour dissocier codeur du test et codeur de la fonctionnalite.

pour la redondance, ça se fait par du pair-programming. et si c'est du test fonctionnel (ou e recette), ça n'a rien à voir je parle du test U.
le test U ça sert à éviter les bug, le test fonc, ça sert à vérifier l'exécution du contrat.

 
certains ont testé mais mal il faut croire ...
est ce que ça plombe les perfs en prod aussi ?

Euh, oui, bien sur
Mais un profiler, c'est pas a utiliser en prod hein

On fait du pair-programming, mais en separant test et codage, on a un minimum de 4 personnes qui ont valide le code, au lieu de 2. Et je ne fais pas de distinction ent test fonctionnel et test U, ils suivent tout deux la meme procedure.
Je ne dis pas que dans ton context cela peut fonctionner, mais chez nous, on est passe de produits avec des bugs journaliers a des produits ou jusqu'a present, en 1 an, un seul bug mineur a ete repertorie par les utilisateurs. Du coup, je ne vois pas pourquoi on prendrait le risque de diminuer la qualite si en bonus on arrive deja a tenir les delais.

C'est du profiling, bien sûr que ça plombe les perfs, et je vois pas ce que ça fout en prod

justement, une question : comment vous profilez vos serveur si vous branchez pas le merdier en prod ? vous copiez le trafic et vous le rejouez ?

DTRACE888

Mais sinon, quand t'as les sous t'as une plateforme d'intégration ISO prod et tu rejoue ton traffic (ou alors tu hammer avec un truc genre Siege)