Tests unitaires ou pas ?

[Frédéric Bouquet]

Hello,

J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des tests unitaires sur les projets JEE. Ce n'est pas la première fois que j'entends des seniors avancer ce type d'arguments dans certains contextes.

Je serais curieux de connaître le retour de la liste sur les contextes où les TU sont utiles ou non, en particulier dans un contexte où le TDD et les tests unitaires apparaissent presque dans les contrats comme propriétés non fonctionnelles des systèmes développés.

(Oui, je sais, nous ne sommes pas vendredi)

Merci

--
Frédéric Bouquet
http://www.espacedefouille.org/

[Jeff MAURY]

Peux tu redonner le pointer sur la source de la discussion ?

Merci
Jeff

2012/6/18 Frédéric Bouquet <bouquet....@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

[Emmanuel Feller]

Salut Frédéric,

J'avoue que j'ai été très content d'entendre Antonio dire à propos des tests u qu'il se sentait gêné à chaque fois qu'on lui posait la question car lui n'en faisait pas ...

Je suis exactement dans la même situation : je ne fais des tests u que lorsqu'il y a un passage très technique et qui se teste sans mocker 36 choses.

Du coup de plus en plus les seuls tests automatisés sont les tests d'intégration (en boite noire).

Clairement avec nos architectures d'entreprises à base de jsf, spring, cxf, ..., 5 lignes de code utile et 20lignes de glue et de xml :  ça devient un tel calvaire pour tester, et expliquer aux débutants quoi tester et comment tester, ou si peu représentatif car à force de tout mocker on ne sait plus ce que l'on teste :/

Finalement j'en reviens au cahier de test papier avec le visa du développeur dessus pour être sûr que le test est fait.

Par contre j'ai beaucoup aimé l'approche d'Antonio sur comment tester son applie de manière globale, je pense que si j'ai l'occasion dans quelques années (l'arrivée de JEE6 chez nous), je le testerai,

My 2c,

Emmanuel

[Antonio Goncalves]

T'es fou de balancer un thread comment ça le lundi, on n'a pas le droit, c'est généralement le vendredi qu'on est autorisé à aborder ces sujets sur LCC. Bon, puisque je suis cité dans le mail, je commence.

Tu parles de senior, et tu as bien raison : moi, j'suis vieux, donc, je suis de plus en plus paresseux : faire tourner un test unitaire dans un environnement managé, c'est la croix et la bannière : tu mock ceci, tu mock cela... tu passes ton temps à mocker. Tu ne vas peut-être pas le croire, mais en 2001 (ouais, je sais, je suis senior), j'avais développé toute une couche de mock à la grosse base de donnée Oracle. Un truc de dingue que plus personne ne fait car on a des bases de données mémoire aujourd'hui (pourquoi mocker l'appel à une base si elle ne prend que 2Mo et réside en mémoire). Alors pourquoi je m’embêterai à mocker l'injection, la transaction, la sécurité.... alors qu'aujourd'hui les containers sont de plus en plus léger et résident en mémoire (merci à Spring d'avoir montré la voie) ? Aujourd'hui, on n'est même plus obligé de mocker les services JMS car il y a des MOMs qui peuvent être utilisé en mémoire. En fait, aujourd'hui, je mock uniquement les services externes qui ne dépendent pas de moi (services web au sens large).

Donc, pour en revenir à ta question, j'utilise les TU, lorsqu'il y a de l'algorithmie pure à tester. Lorsque je me rends compte que je passe plus de temps à utiliser l'API mockito que l'API de mon propre code, j'arrête, je dégaine le conteneur, et je fais des tests en utilisant les services du conteneurs (appelons ça des tests d'intégration).

Donc, ce n'est pas pas : je laisse tomber les TU pour faire uniquement des TI, mais plutôt, en 2012, les TI sont plus simples à faire qu'il y a 5 ans, je ne vais pas m'en priver. Mais c'est vrai que j'ai de moins en moins de TU dans mes projets et de plus en plus de TI. Seul soucis : les TI sont encore un peu longs à s’exécuter... mais bon,  je prédis de nets améliorations dans ce domaine dans les mois/années à venir.

Voilou

Antonio

2012/6/18 Frédéric Bouquet <bouquet....@gmail.com>

--

Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | Blog | LinkedIn | Paris JUG

[Emmanuel Feller]

Antonio,

Je n'ai pas eu le temps de te poser la question après ta prèz, mais je n'ai pas bien compris si tu démarres un conteneur à chaque test. 

Du coup ça m'évoque deux questions :

- si tu redemarres un conteneur à chaque fois, n'y a-t-il pas de solution pour n'en monter qu'un seul ?

- si le conteneur est réutilisé, pourquoi y a-t-il une telle différence de temps d'exécution ?

Merci,

Emmanuel

[Frédéric Bouquet]

C'était lors de la prez d'antonio au Breizhcamp sur les serveurs d'apps.

Frédéric Bouquet
http://www.espacedefouille.org/

[Frédéric Bouquet]

Donc en gros, si l'on résume : 

- Il y a 10 ans, les TU c'était pour limiter la complexité des TI

- Aujoutd'hui les TI sont beaucoup plus simples à faire donc autant tester toute la stack avec une approche fonctionnelle

- Les TU prennent alors leur intérêt pour isoler un problème sur une brique bien identifiée ou pour s'assurer qu'un bout complexe (algo typiquement) est correct.

Finalement, en extrapolant un peu, on va plus chercher à se rapprocher d'une couverture fonctionnelle complète plutôt qu'une couverture complète du code.

Frédéric Bouquet
http://www.espacedefouille.org/

[Nicolas Delsaux]

2012/6/18 Frédéric Bouquet <bouquet....@gmail.com>:

> Donc en gros, si l'on résume :
> - Il y a 10 ans, les TU c'était pour limiter la complexité des TI
> - Aujoutd'hui les TI sont beaucoup plus simples à faire donc autant tester
> toute la stack avec une approche fonctionnelle
> - Les TU prennent alors leur intérêt pour isoler un problème sur une brique
> bien identifiée ou pour s'assurer qu'un bout complexe (algo typiquement) est
> correct.

Euh ...
je suis moyennement d'accord.
Quand j'ai commencé le projet qui m'occupe, j'ai lu religieusement le
bouquin d'Antonio sur les conteneurs légers, Glassfish démarré depuis
maven, tout ça.
J'ai trouvé ça cool, je me suis dit que j'allais faire ça.
Et puis j'ai re-regardé mon EAR dans les yeux.
Et là j'ai vu que je démarrais un neo4j chiément lent à récupérer
toutes mes données de test.
Et que je démarrais un OpenMQ lui aussi complètement mollasson.
Et surtout j'ai découvert qu'un déploiement de mon EAR dans Glassfish
durait environ 30 secondes.
Du coup, maintenant, mes tests unitaires, je les lance depuis un
Glassfish client sur mon Glassfish de dév. Et pas un Glassfish lancé
par maven.
Bien sûr, c'est un peu plus compliqué de configurer Jenkins pour lui
donner le chmin du Glassfish où redéployer l'appli. Mais l'un dans
l'autre, ça marche ... pas super vite. Mais ça marche, ça lance tous
mes tests, et c'est tout ce que je demande (oui, je préfère avoir
plein de tests unitaires d'intégration plutôt que de redéployer en 2
secondes chrono pour tester avec mes yeux).

>
> Finalement, en extrapolant un peu, on va plus chercher à se rapprocher d'une
> couverture fonctionnelle complète plutôt qu'une couverture complète du code.
>

Je parlerai en fait d'une couverture technico-fonctionnelle : j'ai des
tests qui vérifient que les fichiers de binding JNDI côté client sont
bien écrits pour tous les EJBs de mon serveur (et pas générés, à cause
de limitations de Glassfish), j'ai aussi des tests qui vérifient les
temps de réponse de ces EJBs, bref, j'ai des tests pour un paquet d
etrucs quasi-aléatoire, mais ça marche.
Tiens, par exemple, aujourd'hui (ou plutôt vendredi après-midi) j'ai
un test SoapUI (donc avec des bons gros WSDL) qui m'a permis
facilement de détecter qu'un truc foirait dans du code JMS ... Vu de
loin, ça peut sembler dingue, mais dans les faits, les tests sont
raisonnablement bien définis.

--
Nicolas Delsaux

[Emmanuel Lécharny]

Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :

> Hello,
>
> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
> tests unitaires sur les projets JEE.

Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests
unitaires quand tu écris un livre sur J2EE...

Enfin, j'espère.

Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !

> Ce n'est pas la première fois que
> j'entends des seniors avancer ce type d'arguments dans certains contextes.

Le seul contexte où les tests unitaires sont questionnable, amha, c'est
dans le cadre du développement d'une GUI, mais simplement parce que
c'est juste hyper difficile à développer...

En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas - c'est
comme aller sans préservatif dans une back room du Marais...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Emmanuel Lécharny]

Le 6/18/12 10:46 AM, Antonio Goncalves a écrit :

> T'es fou de balancer un thread comment ça le lundi, on n'a pas le droit,
> c'est généralement le vendredi qu'on est autorisé à aborder ces sujets sur
> LCC. Bon, puisque je suis cité dans le mail, je commence.
>
> Tu parles de senior, et tu as bien raison : moi, j'suis vieux, donc, je
> suis de plus en plus paresseux : faire tourner un test unitaire dans un
> environnement managé, c'est la croix et la bannière : tu mock ceci, tu mock
> cela... tu passes ton temps à mocker.

Mais en fait, tu poses la bonne question.

Quand tu fais du J2EE? au final, tu testes quoi ? Les containers ou la
logique métier ?

Perso, je m'en cogne grave de tester qu'un EJB (beuark) retourne
correctement la bonne valeur, ce qui m'intéresse c'est que le
*traitement* encapsulé dans l'EJB retourne bien la bonne valeur. Donc je
ne teste que le traitement, pas l'EJB.

Après, le problème vient du fait que plein de personnes écrivent plein
de code avec plein d'EJBs qui s"invoquent les uns les autres.

J'ai une solution simple : dégagez les EJB de vos applis ! Les EJB,
c'est comme le H de Achille, ça sert A RIEN. Et c'est vrai pour tous les
composants et frameworks que vous utilisez : plus vous rajouterez des
couches, moins vous maîtriserez ce que vous faites, et plus il sera
compliqué de les tester.

Putain, la semaine commence bien, je sais pas si on aura d'autres idées
pour 'dredi :)

[Joseph Pachod]

Perso je trouve surtout que ça monte toutes les limites de l'approche
conteneur... Devoir faire un TI en lieu et place d'un TU parce que le
TU est trop compliqué à mettre en oeuvre, quelle blague!

Et puis quelle joie de débugger un TI qui plante... C'est le code qui
foire ou un des moultes services du conteneur utilisés en test ? Ah
oui, j'oubliais, en prod on utilise un autre conteneur, donc à nouveau
d'autres cas potentiels de non fonctionnement...

N'importe quoi.

Et franchement, devoir mocker 50 classes pour pouvoir faire son test
unitaire, là je dis stop: on regarde le code et on refactore...

NB : ne me lancez pas sur la config XML décriée ci dessus, encore une
riche invention...

2012/6/18 Emmanuel Lécharny <elec...@gmail.com>:

[Emmanuel Lécharny]

Le 6/18/12 11:33 AM, Joseph Pachod a écrit :

> Perso je trouve surtout que ça monte toutes les limites de l'approche
> conteneur... Devoir faire un TI en lieu et place d'un TU parce que le
> TU est trop compliqué à mettre en oeuvre, quelle blague!
>
> Et puis quelle joie de débugger un TI qui plante... C'est le code qui
> foire ou un des moultes services du conteneur utilisés en test ? Ah
> oui, j'oubliais, en prod on utilise un autre conteneur, donc à nouveau
> d'autres cas potentiels de non fonctionnement...
>
> N'importe quoi.
>
> Et franchement, devoir mocker 50 classes pour pouvoir faire son test
> unitaire, là je dis stop: on regarde le code et on refactore...

Tu m'otes de la bouche tout ce que j'ai écris dans un autre mail :)

Mockez vous, mockez-vous...

[Thibaud Vibes]

Moi je suis d'accord avec Antonio. Grâce aux progres dans JEE6 et à des
projets comme Arquillian on écrit plus de tests d'intégrations que de
tests unitaires.
Une base derby à la place de la base de prod quand c'est possible, sinon
on tape sur une copie vide de la base qui est vidé/purgée par DBUnit
avant chaque tests.

Effectivement c'est un peu plus long mais on check bien le comportement
des conteneurs et des framework.

[ehsavoie]

Ouais ben faites les malins mais sur du code legacy sans tests faut
bien mocker pour pouvoir tester afin de pouvoir refactorer et qu'on ne
se mocke plus de nous ;)
----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie


2012/6/18 Emmanuel Lécharny <elec...@gmail.com>:

[Patrice Trognon]

Le 18 juin 2012 à 11:26, Emmanuel Lécharny a écrit :

> Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :
>> Hello,
>>
>> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
>> tests unitaires sur les projets JEE.
> Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests unitaires quand tu écris un livre sur J2EE...
>
> Enfin, j'espère.
>
> Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !

il a quand même pas fait le site de freemobile rassure moi :]

>> Ce n'est pas la première fois que
>> j'entends des seniors avancer ce type d'arguments dans certains contextes.
>
> Le seul contexte où les tests unitaires sont questionnable, amha, c'est dans le cadre du développement d'une GUI, mais simplement parce que c'est juste hyper difficile à développer...

quasi impossible oui sur de l'UI, le seul non, perso je ne couvre que le métier, et encore je rejoins Antonio c'est plus un espèce de truc hybride
entre TU et TI.

>
> En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas - c'est comme aller sans préservatif dans une back room du Marais...
>

bof, essaye tu vas voir on s'en passe très bien, faut pas que l'écriture des tests me prenne plus de temps que le code a tester sinon on
tombe dans un truc délirant.
Bref, utilisation très parcimonieuse on va dire. Et vive mon debugger :)

Par contre un tel sujet pour le lundi matin ....

EL rassure moi, tous ces petits sujets lancé de manière innocente on en viendrai presque à se demander si ce ne serait pas des avatars a toi
qui feraient cela, tu sais la schyzo cela peut se contrôler avec des médicaments hein ;]

Pat

> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

[Nicolas Delsaux]

2012/6/18 Emmanuel Lécharny <elec...@gmail.com>:
> le H de Achille

Ben celui-là il sert à quelque chose ... sinon on parlerait du talon
d'[aSil] (en écriture phonétique, hein).

--->[]

--
Nicolas Delsaux

[Emmanuel Lécharny]

Le 6/18/12 11:36 AM, Thibaud Vibes a écrit :

> Le 18/06/2012 11:26, Emmanuel Lécharny a écrit :
>> Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :
>>> Hello,
>>>
>>> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
>>> tests unitaires sur les projets JEE.
>> Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests
>> unitaires quand tu écris un livre sur J2EE...
>>
>> Enfin, j'espère.
>>
>> Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !
>>> Ce n'est pas la première fois que
>>> j'entends des seniors avancer ce type d'arguments dans certains
>>> contextes.
>>
>> Le seul contexte où les tests unitaires sont questionnable, amha,
>> c'est dans le cadre du développement d'une GUI, mais simplement parce
>> que c'est juste hyper difficile à développer...
>>
>> En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas -
>> c'est comme aller sans préservatif dans une back room du Marais...
>>
> Moi je suis d'accord avec Antonio. Grâce aux progres dans JEE6 et à
> des projets comme Arquillian on écrit plus de tests d'intégrations que
> de tests unitaires.

C'est dangereux.

> Une base derby à la place de la base de prod quand c'est possible,
> sinon on tape sur une copie vide de la base qui est vidé/purgée par
> DBUnit avant chaque tests.
>
> Effectivement c'est un peu plus long mais on check bien le
> comportement des conteneurs et des framework.

Sauf que c'est pas ce que j'ai envie de tester. C'est pas moi qui les ai
écrits, ces frameworks et conteneurs...

Plus sérieusement, je veux bien qu'on utilise un Derby ou autre base en
mémoire, cela dit il y a de sacrées différences entre Oracle et Derby en
terme de fonctionalités... par ailleurs, devoir relancer une base Oracle
à chaque test c'est juste trop pénible, et devoir purger les données de
test c'est aussi pénible...

Bref, pas forcément de solution simple :/

[Thibaud Vibes]

Le 18/06/2012 11:33, Joseph Pachod a écrit :
> Perso je trouve surtout que ça monte toutes les limites de l'approche
> conteneur... Devoir faire un TI en lieu et place d'un TU parce que le
> TU est trop compliqué à mettre en oeuvre, quelle blague!

Je vois pas le problème. Le TI c'est une classe annoté @Test mais qui
lance un conteneur.
Du coup pas besoin de mocker ce que le conteneur apporte.

La solution est donc :
- soit on jete le(s) conteneur(s)
- soit on fait des tests d'intégration à la place des tests unitaires

>
> Et puis quelle joie de débugger un TI qui plante... C'est le code qui
> foire ou un des moultes services du conteneur utilisés en test ? Ah
> oui, j'oubliais, en prod on utilise un autre conteneur, donc à nouveau
> d'autres cas potentiels de non fonctionnement...

C'est faux en 2012 (et même en 2011 et 2010). Mes TI lancent le même
conteneur que celui utilisé pour la prod.

[Jeff MAURY]

2012/6/18 Patrice Trognon <ptro...@gmail.com>

Le 18 juin 2012 à 11:26, Emmanuel Lécharny a écrit :

> Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :
>> Hello,
>>
>> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
>> tests unitaires sur les projets JEE.
> Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests unitaires quand tu écris un livre sur J2EE...
>
> Enfin,  j'espère.
>
> Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !

il a quand même pas fait le site de freemobile rassure moi :]

>> Ce n'est pas la première fois que
>> j'entends des seniors avancer ce type d'arguments dans certains contextes.
>
> Le seul contexte où les tests unitaires sont questionnable, amha, c'est dans le cadre du développement d'une GUI, mais simplement parce que c'est juste hyper difficile à développer...

quasi impossible oui sur de l'UI, le seul non, perso je ne couvre que le métier, et encore je rejoins Antonio c'est plus un espèce de truc hybride
entre TU et TI.

>
> En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas - c'est comme aller sans préservatif dans une back room du Marais...
>

bof, essaye tu vas voir on s'en passe très bien, faut pas que l'écriture des tests me prenne plus de temps que le code a tester sinon on
tombe dans un truc délirant.
Bref, utilisation très parcimonieuse on va dire. Et vive mon debugger :)

Je ne suis pas sur que l'on puisse comparer le temps mis à écrire le code et le temps mis à écrire le code de tests. N'oublions pas que l’écriture d'un test te fait gagner du temps et pas le contraire.

 Jeff

Par contre un tel sujet pour le lundi matin ....

EL rassure moi, tous ces petits sujets lancé de manière innocente on en viendrai presque à se demander si ce ne serait pas des avatars a toi
qui feraient cela, tu sais la schyzo cela peut se contrôler avec des médicaments hein ;]

Pat

> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Rémi Forax]

On 06/18/2012 11:51 AM, Jeff MAURY wrote:
>
>
> 2012/6/18 Patrice Trognon <ptro...@gmail.com <mailto:ptro...@gmail.com>>
>
>
> Le 18 juin 2012 � 11:26, Emmanuel L�charny a �crit :
>
> > Le 6/18/12 10:33 AM, Fr�d�ric Bouquet a �crit :

> >> Hello,
> >>
> >> J'aimerais revenir sur quelques propos d'Antonio sur la non

> utilit� des

> >> tests unitaires sur les projets JEE.

> > Je crois qu'Antonio voulait parler de l'inutilit� d'�crire des
> tests unitaires quand tu �cris un livre sur J2EE...
> >
> > Enfin, j'esp�re.
> >
> > Antonio, c'est toi qui a �crit le site de la SNCF ? Avoue !
>
> il a quand m�me pas fait le site de freemobile rassure moi :]
>
> >> Ce n'est pas la premi�re fois que

> >> j'entends des seniors avancer ce type d'arguments dans certains
> contextes.
> >

> > Le seul contexte o� les tests unitaires sont questionnable,
> amha, c'est dans le cadre du d�veloppement d'une GUI, mais
> simplement parce que c'est juste hyper difficile � d�velopper...

>
> quasi impossible oui sur de l'UI, le seul non, perso je ne couvre

> que le m�tier, et encore je rejoins Antonio c'est plus un esp�ce

> de truc hybride
> entre TU et TI.
>
>
> >

> > En dehors de �a, ne pas �crire de tests unitaires - J2EE ou pas
> - c'est comme aller sans pr�servatif dans une back room du Marais...
> >
>
> bof, essaye tu vas voir on s'en passe tr�s bien, faut pas que
> l'�criture des tests me prenne plus de temps que le code a tester
> sinon on
> tombe dans un truc d�lirant.
> Bref, utilisation tr�s parcimonieuse on va dire. Et vive mon
> debugger :)
>
> Je ne suis pas sur que l'on puisse comparer le temps mis � �crire le
> code et le temps mis � �crire le code de tests. N'oublions pas que
> l��criture d'un test te fait gagner du temps et pas le contraire.
>
> Jeff

Et que ne pas �crire de code (d'appli ou de test) fait encore gagner
plus de temps ...

R�mi

[Thibaud Vibes]

Le 18/06/2012 11:41, Emmanuel Lécharny a écrit :
> Sauf que c'est pas ce que j'ai envie de tester. C'est pas moi qui les
> ai écrits, ces frameworks et conteneurs...

Ben si tu maîtrises bien tous les comportements de tous les framework et
que tu les anticipe bien quand tu codes je suis OK.
Le jour où tu upgrade ton serveur d'app qui fourni des nouvelle version
de chaque couche, t'es bien content d'avoir des tests qui te disent
qu'il y a une regression sur l'impl JPA (je dis ça au hasard) qui
impacte ton appli.

>
> Plus sérieusement, je veux bien qu'on utilise un Derby ou autre base
> en mémoire, cela dit il y a de sacrées différences entre Oracle et
> Derby en terme de fonctionalités... par ailleurs, devoir relancer une
> base Oracle à chaque test c'est juste trop pénible, et devoir purger
> les données de test c'est aussi pénible...

Nous on le fait avec postgres. On redémarre pas la base à chaque fois,
juste on la vide. On est proche en temps d'execution de tests que quand
on utilise une base Derby

>
> Bref, pas forcément de solution simple :/

J'ai pas trouvé ça hardu

[Patrice Trognon]

Le 18 juin 2012 à 11:51, Jeff MAURY a écrit :

2012/6/18 Patrice Trognon <ptro...@gmail.com>

Le 18 juin 2012 à 11:26, Emmanuel Lécharny a écrit :

> Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :
>> Hello,
>>
>> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
>> tests unitaires sur les projets JEE.
> Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests unitaires quand tu écris un livre sur J2EE...
>
> Enfin,  j'espère.
>
> Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !

il a quand même pas fait le site de freemobile rassure moi :]

>> Ce n'est pas la première fois que
>> j'entends des seniors avancer ce type d'arguments dans certains contextes.
>
> Le seul contexte où les tests unitaires sont questionnable, amha, c'est dans le cadre du développement d'une GUI, mais simplement parce que c'est juste hyper difficile à développer...

quasi impossible oui sur de l'UI, le seul non, perso je ne couvre que le métier, et encore je rejoins Antonio c'est plus un espèce de truc hybride
entre TU et TI.

>
> En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas - c'est comme aller sans préservatif dans une back room du Marais...
>

bof, essaye tu vas voir on s'en passe très bien, faut pas que l'écriture des tests me prenne plus de temps que le code a tester sinon on
tombe dans un truc délirant.
Bref, utilisation très parcimonieuse on va dire. Et vive mon debugger :)

Je ne suis pas sur que l'on puisse comparer le temps mis à écrire le code et le temps mis à écrire le code de tests. N'oublions pas que l’écriture d'un test te fait gagner du temps et pas le contraire.

si ils ont du sens oui, c'est bien pour cela que je les limite au code métier comme je disais.

Pat

[Antonio Goncalves]

Tiens, c'est marrant, je suis justement en train de faire un TU en mockant le FacesContext... et le jour où on me donne une API standard pour pouvoir invoquer et configurer mon conteneur web (genre l'API EJBContainer mais version WebContainer) et bah je ferai un TI car ça me simplifiera la vie.

@Joseph, pour "la joie de débugger un TI qui plante" c'est la même qu'avoir des milliers de TU qui passent et une appli qui ne démarre pas. Si tu developpe sur Windows et que tu mets en prod sur Linux, tu risques de découvrir de nouveaux bugs que tu n'avais pas. Si tu developpes sur Tomcat et tu mets en prod sur JBoss, idem. Plus tu tests en condition "réelle", plus tu te couvres (avec ou sans back room d'ailleurs). Les conteneurs te rendent beaucoup de services, et certains sont assez magiques et ont tendance à s'executer derrière ton dos sans que tu ne le sache. Lorsque tu mets ton code testé à l'aide de milliards de mock dans un conteneur, tu te rends compte que le conteneur ne fait pas du tout ce que tu aurais aimé qu'il fasse. 

Les TI sont moins contraignants à écrire qu'avant. Donc maintenant moi, j'en abuse.... je dirai même que dans certains cas j'ai plus de TI que de TU....

Antonio

2012/6/18 Rémi Forax <fo...@univ-mlv.fr>

On 06/18/2012 11:51 AM, Jeff MAURY wrote:

2012/6/18 Patrice Trognon <ptro...@gmail.com <mailto:ptro...@gmail.com>>

   Le 18 juin 2012 à 11:26, Emmanuel Lécharny a écrit :

   > Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :

   >> Hello,
   >>
   >> J'aimerais revenir sur quelques propos d'Antonio sur la non

   utilité des

   >> tests unitaires sur les projets JEE.

   > Je crois qu'Antonio voulait parler de l'inutilité d'écrire des
   tests unitaires quand tu écris un livre sur J2EE...
   >
   > Enfin,  j'espère.
   >
   > Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !

   il a quand même pas fait le site de freemobile rassure moi :]

   >> Ce n'est pas la première fois que

   >> j'entends des seniors avancer ce type d'arguments dans certains
   contextes.
   >

   > Le seul contexte où les tests unitaires sont questionnable,
   amha, c'est dans le cadre du développement d'une GUI, mais
   simplement parce que c'est juste hyper difficile à développer...

   quasi impossible oui sur de l'UI, le seul non, perso je ne couvre

   que le métier, et encore je rejoins Antonio c'est plus un espèce

   de truc hybride
   entre TU et TI.


   >

   > En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas
   - c'est comme aller sans préservatif dans une back room du Marais...
   >

   bof, essaye tu vas voir on s'en passe très bien, faut pas que
   l'écriture des tests me prenne plus de temps que le code a tester
   sinon on
   tombe dans un truc délirant.
   Bref, utilisation très parcimonieuse on va dire. Et vive mon
   debugger :)

Je ne suis pas sur que l'on puisse comparer le temps mis à écrire le code et le temps mis à écrire le code de tests. N'oublions pas que l’écriture d'un test te fait gagner du temps et pas le contraire.

 Jeff

Et que ne pas écrire de code (d'appli ou de test) fait encore gagner plus de temps ...

Rémi

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--

[Moandji Ezana]

Bill Burke a bloggé récemment à ce sujet. Mocks are a Mockery: "With projects like Arquillian and fast boot up times like AS7 (1.75 seconds on my laptop), there’s no need to mock anymore."

Moandji

[Nicolas Labrot]

2012/6/18 Emmanuel Lécharny <elec...@gmail.com>

En quoi c'est pénible? Un drop user et un create user et le tour est joué. L'instance tourne en continu par besoin de l’arrêter / lancer.

 

Bref, pas forcément de solution simple :/

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Emmanuel Lécharny]

Le 6/18/12 1:11 PM, Nicolas Labrot a écrit :
> 2012/6/18 Emmanuel Lécharny<elec...@gmail.com>

>
>>
>> Plus sérieusement, je veux bien qu'on utilise un Derby ou autre base en
>> mémoire, cela dit il y a de sacrées différences entre Oracle et Derby en
>> terme de fonctionalités... par ailleurs, devoir relancer une base Oracle à
>> chaque test c'est juste trop pénible, et devoir purger les données de test
>> c'est aussi pénible...
>>
>
> En quoi c'est pénible? Un drop user et un create user et le tour est joué.
> L'instance tourne en continu par besoin de l’arrêter / lancer.

Pour préciser ma pensée : tu vas devoir purger tes données à chaque
démarrage de test (je parle de chaque test unitaire), ce qui pourra vite
s'avérer super coûteux en temps. Evidemment, cela va dépendre de la
volumétrie de ce que tu manipules.

En pratique, il y a deux façons de faire :
1) précautioneusement nettoyer les seules données modifiées lorsque tu
sors du test
2) purger tout et réinjecter tout à la bourrin.

Las première solution pose problème si tu as une failure...

[David]

Tu m'arrête si je me trompe mais ta problématique semble être :

le composant s’intègre t'il bien sur Tomcat ? le composant s'intègre t'il bien sur JBoss ?

De part ce fait, un test d'intégration est bien plus adapté qu'un test unitaire vu que ce qui t"intéresse c'est la communication entre les composants (et non le comportement d'un composant isolé du monde)

Par contre, je ne comprendrais pas que tu fasse un test d'intégration pour vérifier que la méthode "addition" marche correctement.

[Thibaud Vibes]

La 1) mais c'est pas si compliqué avec DBUnit par exemple. Tu n'injectes
dans la base que les données manipulées/nécessaires pour ton test et
DBUnit purge tout à la fin. Si les insert son fait dans le bon ordre,
les delete le seront aussi. Même en cas de failure.

Je dis pas que de temps en temps t'as pas de faux négatifs à cause de la
gestion des données, mais c'est quand même simple.

[Emmanuel Lécharny]

Le 6/18/12 1:53 PM, Thibaud Vibes a écrit :

Pas faux, pas faux...

[ehsavoie]

Sauf en cas d'outofmemory ou de kill de la vm

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie


2012/6/18 Emmanuel Lécharny <elec...@gmail.com>:

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail

> à lescast...@googlegroups.com.

> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse

> lescastcodeur...@googlegroups.com.

[Thibaud Vibes]

Le 18/06/2012 14:28, ehsavoie a écrit :

Sauf en cas d'outofmemory ou de kill de la vm

Si si :-) Nous on a une purge AVANT l'insertion (j'ai oublié de le mentionner) au cas où il resterait des saletés qui n'ont pas été supprimées parce que la VM a crashé.
Donc voici comment ça se déroule pour chaque tests :
- DELETE <- la BDD est propre
- INSERT
- Test d'intégration
- DELETE

(Arquillian démarre les conteneurs, non pas avant chaque tests par contre, mais 1 fois pour chaque classe de test)


Le seul problème qu'on a c'est lorsqu'on ne peut tester avec une base embarquée et qu'on utilise une base de tests => si on fait du build à 2 en même temps (sans passer par le serveur de CI qui gère des files d'attentes) on a des collisions.

[Altus34]

2012/6/18 Emmanuel Lécharny <elec...@gmail.com>

Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :

Hello,

J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
tests unitaires sur les projets JEE.

Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests unitaires quand tu écris un livre sur J2EE...

Enfin,  j'espère.

Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !

Ce n'est pas la première fois que
j'entends des seniors avancer ce type d'arguments dans certains contextes.

Le seul contexte où les tests unitaires sont questionnable, amha, c'est dans le cadre du développement d'une GUI, mais simplement parce que c'est juste hyper difficile à développer...

Plus maintenant. Perso je fait meme du Test First sur mon UI (oui j'écris mon test de UI AVANT)

https://github.com/Ovea/testatoo-documentation/blob/master/doc/manual/src/chapters/010-intro.md

 

En dehors de ça, ne pas écrire de tests unitaires - J2EE ou pas - c'est comme aller sans préservatif dans une back room du Marais...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Thibaud Vibes]

Le 18/06/2012 14:52, Thibaud Vibes a écrit :

Le 18/06/2012 14:28, ehsavoie a écrit :

Sauf en cas d'outofmemory ou de kill de la vm

Si si :-) Nous on a une purge AVANT l'insertion (j'ai oublié de le mentionner) au cas où il resterait des saletés qui n'ont pas été supprimées parce que la VM a crashé.
Donc voici comment ça se déroule pour chaque tests :
- DELETE <- la BDD est propre
- INSERT
- Test d'intégration
- DELETE

Bon du coup le dernier delete semble inutile X-D
C'est bien la ML des cast codeurs ça nous force à expliquer nos process et du coup on voit les failles.

[Nicolas Delsaux]

2012/6/18 Thibaud Vibes <thibau...@wanadoo.fr>:

> Si si :-) Nous on a une purge AVANT l'insertion (j'ai oublié de le
> mentionner) au cas où il resterait des saletés qui n'ont pas été supprimées
> parce que la VM a crashé.
> Donc voici comment ça se déroule pour chaque tests :
> - DELETE <- la BDD est propre
> - INSERT
> - Test d'intégration
> - DELETE
>
> Bon du coup le dernier delete semble inutile X-D
> C'est bien la ML des cast codeurs ça nous force à expliquer nos process et
> du coup on voit les failles.
>

Disons que si t'étais super sioux, tu rajouterais une vérification
"standard" après ce dernier DELETE pour voir si tout a bien été
supprimé.
Comme ça, tu vérifie que ton test est bon (ça c'est standard) et en
bonus tu vérifie qu'il n'affecte bien que les données auxquelles tu
penses. Chez les paranos, ça fait stylé :-D

>
>
> (Arquillian démarre les conteneurs, non pas avant chaque tests par contre,
> mais 1 fois pour chaque classe de test)
>
>
> Le seul problème qu'on a c'est lorsqu'on ne peut tester avec une base
> embarquée et qu'on utilise une base de tests => si on fait du build à 2 en
> même temps (sans passer par le serveur de CI qui gère des files d'attentes)
> on a des collisions.
>
>

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail
> à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr

--
Nicolas Delsaux

[Emmanuel Lécharny]

Le 6/18/12 2:58 PM, Altus34 a écrit :

> 2012/6/18 Emmanuel Lécharny<elec...@gmail.com>
>
>> Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :
>>
>> Hello,
>>> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
>>> tests unitaires sur les projets JEE.
>>>
>> Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests
>> unitaires quand tu écris un livre sur J2EE...
>>
>> Enfin, j'espère.
>>
>> Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !
>>
>> Ce n'est pas la première fois que
>>> j'entends des seniors avancer ce type d'arguments dans certains contextes.
>>>
>> Le seul contexte où les tests unitaires sont questionnable, amha, c'est
>> dans le cadre du développement d'une GUI, mais simplement parce que c'est
>> juste hyper difficile à développer...
>>
>
> Plus maintenant. Perso je fait meme du Test First sur mon UI (oui j'écris
> mon test de UI AVANT)
> https://github.com/Ovea/testatoo-documentation/blob/master/doc/manual/src/chapters/010-intro.md

Je parlais de GUI, pas de WebUI.

[Altus34]

Moi aussi ;) 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Emmanuel Lécharny]

Le 6/18/12 3:55 PM, Altus34 a écrit :

> 2012/6/18 Emmanuel Lécharny<elec...@gmail.com>
>
>> Le 6/18/12 2:58 PM, Altus34 a écrit :
>>
>> 2012/6/18 Emmanuel Lécharny<elec...@gmail.com>
>>> Le 6/18/12 10:33 AM, Frédéric Bouquet a écrit :
>>>> Hello,
>>>>
>>>>> J'aimerais revenir sur quelques propos d'Antonio sur la non utilité des
>>>>> tests unitaires sur les projets JEE.
>>>>>
>>>>> Je crois qu'Antonio voulait parler de l'inutilité d'écrire des tests
>>>> unitaires quand tu écris un livre sur J2EE...
>>>>
>>>> Enfin, j'espère.
>>>>
>>>> Antonio, c'est toi qui a écrit le site de la SNCF ? Avoue !
>>>>
>>>> Ce n'est pas la première fois que
>>>>
>>>>> j'entends des seniors avancer ce type d'arguments dans certains
>>>>> contextes.
>>>>>
>>>>> Le seul contexte où les tests unitaires sont questionnable, amha, c'est
>>>> dans le cadre du développement d'une GUI, mais simplement parce que c'est
>>>> juste hyper difficile à développer...
>>>>
>>>>
>>> Plus maintenant. Perso je fait meme du Test First sur mon UI (oui j'écris
>>> mon test de UI AVANT)

>>> https://github.com/Ovea/**testatoo-documentation/blob/**
>>> master/doc/manual/src/**chapters/010-intro.md<https://github.com/Ovea/testatoo-documentation/blob/master/doc/manual/src/chapters/010-intro.md>

>>>
>> Je parlais de GUI, pas de WebUI.
>>
>>
>>
> Moi aussi ;)

je vois pas bien comment tu vas pouvoir lancer un test qui vérifie
automatiquement que la zone d'affichage en 217x1000 va contenir l'image
attendue...

[Patrice Trognon]

franchement si toutes les règles de design étaient complètement vérifiable par des process automatiques
ils ne se feraient pas suer chez apple a embaucher des mecs a faire des tests d'ui à la msin pour vérifier
si les UI-Guideline sont respectés !

Donc je suis en phase avec EL, l'automatisation de tests d'UI on en voir vite les limites, va donc valider des
opérations de drag&drop.

Pat

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Nicolas Delsaux]

2012/6/18 Emmanuel Lécharny <elec...@gmail.com>:

>
>
> je vois pas bien comment tu vas pouvoir lancer un test qui vérifie
> automatiquement que la zone d'affichage en 217x1000 va contenir l'image
> attendue...
>

Project Sikuli ? (http://sikuli.org/) et avec des tests dans maven, en
bonus ! (http://javasplitter.blogspot.fr/2011/02/continuous-gui-integration-testing.html)

--
Nicolas Delsaux

[Altus34]

En effet et je n'en vois pas l'interet (de meme de savoir que mon image est bien une image en HD si mon termianl a un pixelratio de 2 ;))

Mais bon c'est faisable.

Apres la vrai question est ton ROI, donc ton rapport cout investit / gain ;)

Perso je ne me concentre que sur deux types de des tests 

1 - Comment mon utilisateur interagit avec mon system avec le UI pour realiser un operation business. (test de fonctionalite)

2 - quels sont les élments qui doivent être présent/absent de mon UI pour la réalisation de cette operation business (test d'éran)

exemple :

1 - Test de la fonction => expression de l'intention business pure. 

 @Test

    public void a_message_is_displayed_if_email_authentication_fail() throws Exception {

        assertThat(isLogged(), is(false));

        page().open("/");

        clickOn(connexionLink());

        clickOn(loginByEmailLink());

        enter("joel.c...@muc.mpl", on(emailField()));

        enter("bad-password", on(passwordField()));

        clickOn(loginButton());

        assertThat(loginErrorPanel(), is(visible()));

        assertThat(loginErrorPanel(), has(text("Email ou mot de passe invalide")));

        assertThat(isLogged(), is(false));

    }

2 - Test de l'ecran

@Test

    public void test_security_page() {

        assertThat(securityWindow(), is(not(visible())));

        clickOn(connexionLink());

        assertThat(securityWindow(), is(visible()));

        assertThat(facebookLoginPanel(), is(visible()));

        and(it(), has(title("Connectez-vous en 1 clic avec Facebook")));

        assertThat(emailLoginPanel(), is(not(visible())));

        assertThat(registerPanel(), is(not(visible())));

        clickOn(loginByEmailLink());

        assertThat(emailLoginPanel(), is(visible()));

        assertThat(registerPanel(), is(not(visible())));

        assertThat(emailLoginPanel(), has(title("Connectez-vous avec votre email")));

        and(it(), displays(

                emailField(),

                passwordField(),

                loginButton(),

                lostPasswordLink()

        ));

.....

 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Emmanuel Lécharny]

Le 6/18/12 5:17 PM, Altus34 a écrit :

>>>>> https://github.com/Ovea/****testatoo-documentation/blob/**<https://github.com/Ovea/**testatoo-documentation/blob/**>
>>>>> master/doc/manual/src/****chapters/010-intro.md<https://**
>>>>> github.com/Ovea/testatoo-**documentation/blob/master/doc/**
>>>>> manual/src/chapters/010-intro.**md<https://github.com/Ovea/testatoo-documentation/blob/master/doc/manual/src/chapters/010-intro.md>

>>>>> Je parlais de GUI, pas de WebUI.
>>>>
>>>>
>>>> Moi aussi ;)
>> je vois pas bien comment tu vas pouvoir lancer un test qui vérifie
>> automatiquement que la zone d'affichage en 217x1000 va contenir l'image
>> attendue...
>>
>>
>>
> En effet et je n'en vois pas l'interet (de meme de savoir que mon image est
> bien une image en HD si mon termianl a un pixelratio de 2 ;))
> Mais bon c'est faisable.
>
> Apres la vrai question est ton ROI, donc ton rapport cout investit / gain ;)
> Perso je ne me concentre que sur deux types de des tests
>
> 1 - Comment mon utilisateur interagit avec mon system avec le UI pour
> realiser un operation business. (test de fonctionalite)
> 2 - quels sont les élments qui doivent être présent/absent de mon UI pour
> la réalisation de cette operation business (test d'éran)

Je ne vois toujours pas comment tu vérifies que ton appli t'affiche bien
toutes les données que tu attends, quand par exemple ton appli est
écrite en SWT, en Swing, etc...

A part faire une saisie d'écran préalable ?

Ou alors, c'est de l'ultra spécifique.

[Pierre-Yves Ricau]

Pour la UI, jcrois que la mise en prod reste le meilleur des tests (pas taper, pas taper) :) .

1) Tu déploies une modification pour une partie de tes utilisateurs seulement.
2) Tu as du monitoring "fonctionnel" en place qui te permet d'être rapidement alerté si le nombre d'utilisateur qui atteignent telle étape / vont au bout de tel workflow chute (parmi les utilisateurs ayant eu la modif). Voir même éventuellement un rollback automatique et redéploiement.

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Pierre-Yves Ricau

http://www.piwai.info

[Altus34]

C'est ce que je nomme un test d'écran (cf test cas 2)

quand par exemple ton appli est écrite en SWT, en Swing, etc...

Tu gardes le meme test et tu change de cartouche on a une cartouche Html4 mais aussi du Flex en beta qui tourne pour du SWT ou Swing il faudrait l'écrire (on est pas specialiste de ces technos mias ca se fait)

Apres on est Ok que tu ne remplacera pas l'oeil humain ca c'est sure mais tu va le conserver pour une revue de HAUT niveau.

Ce que tu va remplacer ce sont les gars qui executent manuelement des tonnes de tests a partir de cahier de recette sans meme comprendre parfois ce qu'il tests (pas de connaissance métier).

A part faire une saisie d'écran préalable ?

Ou alors, c'est de l'ultra spécifique.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Nicolas Labrot]

L'approche qunit me convient plus. Plus bas niveau, je peux tester et le coté visible de l'UI et les librairies JS derrière.

Mais on s'écarte du sujet ;)

2012/6/18 Altus34 <alt...@gmail.com>

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Emmanuel Lécharny]

Le 6/18/12 6:30 PM, Altus34 a écrit :
> 2012/6/18 Emmanuel Lécharny<elec...@gmail.com>
>
>>

>> Je ne vois toujours pas comment tu vérifies que ton appli t'affiche bien
>> toutes les données que tu attends,
>
> C'est ce que je nomme un test d'écran (cf test cas 2)
>
> quand par exemple ton appli est écrite en SWT, en Swing, etc...
>
> Tu gardes le meme test et tu change de cartouche on a une cartouche Html4
> mais aussi du Flex en beta qui tourne pour du SWT ou Swing il faudrait
> l'écrire

On est bien d'accord : en fait, testatoo gère du test de web UI, pas
d'autre chose (sauf Flex). La *grosse* différence, c'est qu'en HTML, tu
peux te parser le HTML et vérifier qu'il contient bien ce que tu attends
par pattern matching ou autre. Sur une GUI, swing ou SWT ou cocoa, bon
courage ! Il faut soit trapper les events, soit se taper les écran, avec
tous les pb que ça pose. En RCP, il y a un truc qui s'appelle SWTBot
(http://www.eclipse.org/swtbot/) mais c'est franchement spécifique.
Visiblement, il y a d'autres outils (Sikuli) pour d'autres environnements.

La GUI, c'est pas super simple à tester ! Vivement qu'on arrête de faire
de la GUI pure et qu'on s'appuie systématiquement sur un moteur de
présentation style webKit... C'est marrant, d'ailleurs, du temps de X11,
faire des tests unitaires d'écran aurait été assez simple, puisque les
affichages étaient gérés par le terminal mais en traitant un format de
présentation bien définit. Régression ?

[Baptiste MATHUS]

Le 18 juin 2012 11:33, "Emmanuel Lécharny" <elec...@gmail.com> a écrit :

> J'ai une solution simple : dégagez les EJB de vos applis ! Les EJB, c'est comme le H de Achille, ça sert A RIEN. Et c'est vrai

Sans h, Achille ça se dit assile ou un truc comme ça. C'est donc indispensable. Comme les EJB donc ? :)

[Altus34]

2012/6/18 Emmanuel Lécharny <elec...@gmail.com>

Le 6/18/12 6:30 PM, Altus34 a écrit :

2012/6/18 Emmanuel Lécharny<elec...@gmail.com>

Je ne vois toujours pas comment tu vérifies que ton appli t'affiche bien
toutes les données que tu attends,

C'est ce que je nomme un test d'écran (cf test cas 2)

quand par exemple ton appli est écrite en SWT, en Swing, etc...

Tu gardes le meme test et tu change de cartouche on a une cartouche Html4
mais aussi du Flex en beta qui tourne pour du SWT ou Swing il faudrait
l'écrire

On est bien d'accord : en fait, testatoo gère du test de web UI, pas d'autre chose (sauf Flex).

Non pas pour le moment car nous n'avons pas cette expertise

 

La *grosse* différence, c'est qu'en HTML, tu peux te parser le HTML et vérifier qu'il contient bien ce que tu attends par pattern matching ou autre. Sur une GUI, swing ou SWT ou cocoa, bon courage ! Il faut soit trapper les events, soit se taper les écran, avec tous les pb que ça pose. En RCP, il y a un truc qui s'appelle SWTBot (http://www.eclipse.org/swtbot/) mais c'est franchement spécifique. Visiblement, il y a d'autres outils (Sikuli) pour d'autres environnements.

Non et c'est pour ca que nous avons fait une preuve de concept avec Flex qui pose les mêmes problèmes que Swing, SWT et autre. Le principe est d'avoir un agent encapsulé dans ton app en mode test qui est interogable depuis l'extérieur. Tu intergoge ton agent sur l'état interne de ton app.

La GUI, c'est pas super simple à tester ! Vivement qu'on arrête de faire de la GUI pure et qu'on s'appuie systématiquement sur un moteur de présentation style webKit... C'est marrant, d'ailleurs, du temps de X11, faire des tests unitaires d'écran aurait été assez simple, puisque les affichages étaient gérés par le terminal mais en traitant un format de présentation bien définit. Régression ?

Non en effet et c'est ce qui fait que les app web on un ENORME avantage => Plus facile a faire un UI Web que SWT, plus facile a tester, plus facile a déployer ....

 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Patrice Trognon]

tu pouvais surtout poster assez simplement les evt X11 et donc rejouer un scénario, idem sur windows j'avais du code qui faisait ça sous windows 3.1
ca marchait nickel, suffisait de choper les HWND des différents elements et ensuite de leur poster les messages WM_, ils y voyaient que du feu.

Sur un Swing vu que tout est géré par la VM .... je ne sais pas.
sur Mac y'a bien des solutions pour enregistrer un scénario et le rejouer, mais bon pour ce que j'ai pu tester cela déraille assez vite.


Pat

> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[ehsavoie]

Pour Swing y a http://docs.codehaus.org/display/FEST/Swing+Module qui
vit depuis pas mal de temps.
Les enregistreurs de scenarii pour suivre la souris / clavier ca
fonctionne mais c'est clair que ca reste light.
De toute façon une IHM a un H comme Achille et comme Humain et que
donc au final il te reste tes deux yeux pour pleurer devant l'écran à
compter les pixels.

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/6/18 Patrice Trognon <ptro...@gmail.com>:

[Frédéric Delorme]

Perso, je m'en cogne grave de tester qu'un EJB (beuark) retourne correctement la bonne valeur, ce qui m'intéresse c'est que le *traitement* encapsulé dans l'EJB retourne bien la bonne valeur. Donc je ne teste que le traitement, pas l'EJB.

Après, le problème vient du fait que plein de personnes écrivent plein de code avec plein d'EJBs qui s"invoquent les uns les autres.

J'ai une solution simple : dégagez les EJB de vos applis ! Les EJB, c'est comme le H de Achille, ça sert A RIEN.

Comment je suis trop d'accord :)

Je préfère largement maîtriser mon code que laisser Spring ou autre framewok tout faire pour moi. Parce que le jour où un bug dans les couches d'injection/d'encapsulation/etautre... se produit:  bonjour la séance prise de tête de débuggage avec votre ide préféré :)

Gardons la main !

Cela dit, j'utilise aussi spring de temps en temps, c'est bien pratique pour les instanciations. 

Par contre, s'il vous plait, arrêtez de mettre du Spring partout (ceci est un message aux développeurs en général :) parce que au bout d'un moment, les développeurs ne savent plus faire sans et s'éloigne du précepte "keep it simple" :) (et en plus perde les compétence en Java pur)

McG. aka Frédéric Delorme

_______________________________

Solution Architect

mail: frederic...@gmail.com

twits on: http://twitter.com/McGivrer/

posts on: http://www.mcgivrer.fr/

[Julien Herr]

Mais quand tu dois composer avec des équipes qui n'ont de toute façon pas/plus ces compétences ? Ce n'est, du coup, pas moins risqué d'utiliser Spring (ou autre) et éviter qu'ils écrivent de la dette ?

J'avoue que c'est encore plus dur s'il y a des problèmes dans ces boites noires.

(J'ai peur qu'on s'éloigne un peu du sujet d'origine pour le coup)

[Thibaud Vibes]

Le 19/06/2012 14:03, Frédéric Delorme a écrit :

Perso, je m'en cogne grave de tester qu'un EJB (beuark) retourne correctement la bonne valeur, ce qui m'intéresse c'est que le *traitement* encapsulé dans l'EJB retourne bien la bonne valeur. Donc je ne teste que le traitement, pas l'EJB.

Après, le problème vient du fait que plein de personnes écrivent plein de code avec plein d'EJBs qui s"invoquent les uns les autres.

J'ai une solution simple : dégagez les EJB de vos applis ! Les EJB, c'est comme le H de Achille, ça sert A RIEN.

Comment je suis trop d'accord :)

Je préfère largement maîtriser mon code que laisser Spring ou autre framewok tout faire pour moi. Parce que le jour où un bug dans les couches d'injection/d'encapsulation/etautre... se produit:  bonjour la séance prise de tête de débuggage avec votre ide préféré :)

- tests d'intégration
- tests d'intégration
- tests d'intégration
Et là tu maîtrise ton code ET ton appli.

Gardons la main !

Pour anticiper certaines remarques et répondre à l'une de Emmanuel L. (dans un précédent message), je cite (à peu près) "c'est pas le conteneur EJB que j'ai envie de tester ..."
=> les tests d'intégration permettent de vérifier le fonctionnement global de TON appli.
Ensuite que ce comportement soit codé entièrement à la main où apporté par des framework on s'en fout. D'ailleurs, une fois un test en place, on peut virer une couche codée à la main pour mettre un EJB (ou l'inverse) et le test est là pour valider que le traitement se fait toujours bien.

Perso je trouve étrange les devs qui veulent tout recoder. Dites moi, vous codez les vérifications d'intégrité avant d'insérer dans la bdd? Ah ben non je suis bête vous insérez dans un fichier, une bdd ça fait trop de trucs qu'on maîtrise pas... 

Cela dit, j'utilise aussi spring de temps en temps, c'est bien pratique pour les instanciations. 

Par contre, s'il vous plait, arrêtez de mettre du Spring partout (ceci est un message aux développeurs en général :) parce que au bout d'un moment, les développeurs ne savent plus faire sans et s'éloigne du précepte "keep it simple" :) (et en plus perde les compétence en Java pur)

Encore une fois KISS et EJB ne sont pas contradictoire. Faut arréter de sortir cet acronyme tout le temps, il perd de sa magie.

Y a pas plus KISS qu'un EJB en 2012.

McG. aka Frédéric Delorme

Thibaud aka Integration Man

[Joseph Pachod]

Ca s'enflamme et j'ai même pas le temps d'intervenir, snif

Perso je n'arrive pas à comprendre comment on peut tester la même
chose dans un test unitaire et dans un test d'intégration. Le test
unitaire a une portée forcément bien moindre, il ne devrait même pas
faire appel à tous les services divers du conteneur.

Partant de là je vois mal comment on gagne avec le test d'intégration,
qui ne fait que rajouter d'autres sources potentielles de plantage
ainsi qu'une durée de lancement accrue.... Même un surcout d'une
seconde par classe de test me parait trop cher payé pour mes tests
unitaires...

2012/6/19 Thibaud Vibes <thibau...@wanadoo.fr>:

[Antonio Goncalves]

Ah, le syndrome "Not Invented Here" est de retour. C'est surement du à mon grand age, une fois de plus, mais je n'ai plus la prétention de développer un driver JDBC ou un connecteur transactionnel mieux que les librairies qui existent depuis 10 ans. Je ne développe pas d'APIs mais des applications pour mes clients. Je suis donc content d'utiliser un fwk d'injection plutôt que de réinventer le mien.... mais c'est certainement du à mon grand age... ou à la ribambelle de projets par lesquels je suis passé qui avait "développé leur propre ORM (car Hibernate c'est pourri) mais les développeurs ont quitté la boite".

Antonio

2012/6/19 Frédéric Delorme <frederic...@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | Blog | LinkedIn | Paris JUG

[Manu]

+1 en effet

2012/6/19 Antonio Goncalves <antonio....@gmail.com>

[Thibaud Vibes]

Le 19/06/2012 14:34, Joseph Pachod a écrit :
> Ca s'enflamme et j'ai même pas le temps d'intervenir, snif

Bon c'est vrai...

>
> Perso je n'arrive pas à comprendre comment on peut tester la même
> chose dans un test unitaire et dans un test d'intégration. Le test
> unitaire a une portée forcément bien moindre, il ne devrait même pas
> faire appel à tous les services divers du conteneur.
>
> Partant de là je vois mal comment on gagne avec le test d'intégration,
> qui ne fait que rajouter d'autres sources potentielles de plantage
> ainsi qu'une durée de lancement accrue.... Même un surcout d'une
> seconde par classe de test me parait trop cher payé pour mes tests
> unitaires...

ça colle pas avec du infinitest c'est sur...
Perso je ne double pas les tests unitaires avec des tests d'intégration.
Je fais comme Antonio l'à dit, j'ai tendance à faire que des tests
d'intégration.

Un exemple:

@Stateless
public class MonKISSEJB{
@PersistenceContext
protected EntityManager em;

public void addOnlyOnce(Client c){
em.persist(c);
}
}

On va pas faire un TU pour si peu de code? Pourtant j'aimerais vérifier
que mon appli n'ajoute qu'une seule fois une entité Client (et quelle
lève une exception ou ignore l'insertion la deuxième fois peu importe).
=> Et bien je peu écrire un test d'intégration.

Que la contrainte soit implantée dans la bdd, via un intercepteur, ...
le test d'intégration vérifie que ça marche. Le jour où je déplace la
vérification le test m'aide à vérifier que j'ai toujours le comportement
attendu.
Avec des mock c'est + compliqué ils figent un comportement qui n'est pas
forcément celui qu'on aura en recette/prod. Et il fait maintenir le code
qui mock pour être sûr qu'il colle toujours au comportement final.

Après je fais pas beaucoup de Spring, mais avec JEE on réflechi pas à
mocker, on test direct avec le conteneur final.
Je trouve que c'est pratique.

[David Screve]

Sous iOS, ya un framework de test unitaire de GUI assez bien
foutu....mais personne ne s'en sert parce que justement, le ROI est
proche de zéro par rapport à un vrai utilisateur.

On 18 juin, 22:22, Patrice Trognon <ptrog...@gmail.com> wrote:
> Le 18 juin 2012 à 19:31, Emmanuel Lécharny a écrit :
>
>
>
>
>
>
>
>
>
> > Le 6/18/12 6:30 PM, Altus34 a écrit :

> >> 2012/6/18 Emmanuel Lécharny<elecha...@gmail.com>

[Thibaud Vibes]

Le 19/06/2012 14:41, Antonio Goncalves a écrit :
> Ah, le syndrome "Not Invented Here" est de retour. C'est surement du à
> mon grand age, une fois de plus, mais je n'ai plus la prétention
> de développer un driver JDBC ou un connecteur transactionnel mieux que
> les librairies qui existent depuis 10 ans. Je ne développe pas d'APIs
> mais des applications pour mes clients. Je suis donc content
> d'utiliser un fwk d'injection plutôt que de réinventer le mien....
> mais c'est certainement du à mon grand age... ou à la ribambelle de
> projets par lesquels je suis passé qui avait "développé leur propre
> ORM (car Hibernate c'est pourri) mais les développeurs ont quitté la
> boite".
>
> Antonio

+1

[Nicolas Labrot]

C'est qu'il n'est pas bien foutu si le ROI est proche de zéro. ;)

2012/6/19 David Screve <david....@gmail.com>

[Nicolas Labrot]

+1, le vieux sage a parlé!

2012/6/19 Antonio Goncalves <antonio....@gmail.com>

[Joseph Pachod]

Merci pour cette longue réponse Thibaud

Dans le cas que tu mets en avant, perso, ce n'est pas un test unitaire
mais un test d'hibernate/JPA, autrement dit un test de code qui ne
t'appartient pas. Et si je trouve que ces tests ont également leur
place, ce n'est pas des tests unitaires AMHA.

D'ailleurs, pour illustrer la chose, j'espère que chaque fois qu'un
dév code quelque chose comme:

public void addOnlyOnce(Client c){
em.persist(c);
}

il ne réécrit pas un test d'intégration correspondant pour s'assurer
du fonctionnement d'hibernate, parce que bonjour les dizaines de tests
similaires pour une valeur ajoutée nulle.

perso je dirai plutot que cela doit trouver sa place dans un projet de
test genre "hibernate-test", où chaque dév pourra aller voir si ce
bout de code a un comportement connu. D'ailleurs dans l'absolu ce
serait bien que qq'un refactore un peu ce code pour pouvoir faire
usage de composition plutôt que d'héritage. Après tout, addOnlyOnce me
semble transverse et non lié au KissEjb courant.

bref, on en revient à ce que je disais; ce n'est pas du test unitaire AMHA

++

[Antonio Goncalves]

Attention, tu oublies qque chose : souvent, c'est le DBA qui écrit les scripts de création/mise à jour/migration des données. C'est à dire que ton em.persist(c) fonctionne en dev car t'es en mode "drop-create-table", mais cela n'arrive jamais en prod. Donc, en pré-prod, tu passes tes 1001 scripts de modifications de schéma, tes 1001 scripts de migration de données, et si avant de te lancer dans des tests d'IHM tu peux au moins faire fonctionner ton em.persist(c), et bah t'es content.

Antonio

2012/6/19 Joseph Pachod <joseph...@gmail.com>

--

[Patrice Trognon]

héhé, bien joué Nicolas :)

Je pense que c'est plus culturel en fait, dans l'UI c'est tellement long et chiant à développer pour des résultats pas forcement intéressant.

Comme je disais dans une autres réponse j'aurai tendance à limiter les TU/TI au code métier, le reste est testé humainement.

de toute façon le test d'UI, et c'est justement la dedans que je suis cette semaine, cela tourne vite a vérifier si y'a pas une putain

ligne de 1 point d'épaisseur qui apparait a gauche parce que l'objet de l'image de fond est mal positionné, et ça mis a part lancer

et faire tourner pour vérifier que tous les objets sont bien alignés, proportionnés, avec les mêmes fontes, etc etc....

Pat

[Nicolas Delsaux]

2012/6/19 Patrice Trognon <ptro...@gmail.com>:

> héhé, bien joué Nicolas :)
>
> Je pense que c'est plus culturel en fait, dans l'UI c'est tellement long et
> chiant à développer pour des résultats pas forcement intéressant.

Mouarf ...
Ceux que j'ai fait en Swing ne m'ont jamais paru bien complexes à
écrire ... avec FEST-assert.

>
> Comme je disais dans une autres réponse j'aurai tendance à limiter les TU/TI
> au code métier, le reste est testé humainement.
>
> de toute façon le test d'UI, et c'est justement la dedans que je suis cette
> semaine, cela tourne vite a vérifier si y'a pas une putain
> ligne de 1 point d'épaisseur qui apparait a gauche parce que l'objet de
> l'image de fond est mal positionné, et ça mis a part lancer
> et faire tourner pour vérifier que tous les objets sont bien alignés,
> proportionnés, avec les mêmes fontes, etc etc....
>

Et donc, pour vérifier ça, tu préfères examiner une fois l'interface à
la main avec un inspecteur (si tant est que ça existe dans cet
environnement ... spécifique), ou écrire le test unitaire qui
correspond pile poil à ta vérification manuelle et l'exécuter en
intégration continue (je sais déja ce que je répondrais, hein).

En fait, sous le troll, ce que je questionne, c'est la perception de
la difficulté.
Qu'est-ce qui fait, selon toi, que c'est compliqué de vérifier
(d'après un patron éventuellement - c'est-à-dire un lancement manuel
avec extraction de l'arbre des propriétés des widgets) que les widgets
ont bien les propriétés que tu souhaite qu'ils ont de manière
automatique (et donc vérifiant la non-régression) ?

--
Nicolas Delsaux

[Thibaud Vibes]

Je ne suis pas tout à fait d'accord.

Pour moi le test d'intégration vérifie le BON EMPLOI d'hibernate/JPA. Si
la contrainte est générée par hbm2ddl par exemple il faut une annotation
@UniqueConstraint
C'est hibernate qui gère mais c'est au dev de la mettre en place (donc
c'est son code). Mais moi au final je m'en fout que ce soit Hibernate
qui gère, je vais être sûr que je ne vais pas avoir 2 clients identiques
dans ma bdd.

Donc je dirais que le test ne teste pas hibernate mais plutôt la bonne
utilisation d'hibernate par rapport à ce qu'on souhaite. Et comme je
disais, si on change la façon de vérifier l'unicité (et donc l'impl de
addOnlyOnce) on ne change pas le test. Donc cela veut dire qu'on ne
teste pas Hibernate au final. #cqfd

Thibaud

[David Screve]

Ben si, il est bien foutu...mais tester une IHM multitouch, avec des
animations, des trucs qui bougent de partout, ça présente assez peu
d'intérêt...tu vas passer 2 h à développer un bout de code pour tester
un mouvement de doigt d'une demi seconde....et en plus ton framework
ne te permettra pas de mesurer le rendu graphique...

On 19 juin, 15:12, Nicolas Labrot <nith...@gmail.com> wrote:
> C'est qu'il n'est pas bien foutu si le ROI est proche de zéro. ;)
>

> 2012/6/19 David Screve <david.scr...@gmail.com>

[Rémi Forax]

On 06/19/2012 03:43 PM, Patrice Trognon wrote:
> h�h�, bien jou� Nicolas :)

>
> Je pense que c'est plus culturel en fait, dans l'UI c'est tellement

> long et chiant � d�velopper pour des r�sultats pas forcement int�ressant.
>
> Comme je disais dans une autres r�ponse j'aurai tendance � limiter les
> TU/TI au code m�tier, le reste est test� humainement.
>
> de toute fa�on le test d'UI, et c'est justement la dedans que je suis
> cette semaine, cela tourne vite a v�rifier si y'a pas une putain
> ligne de 1 point d'�paisseur qui apparait a gauche parce que l'objet
> de l'image de fond est mal positionn�, et �a mis a part lancer
> et faire tourner pour v�rifier que tous les objets sont bien align�s,
> proportionn�s, avec les m�mes fontes, etc etc....
>
> Pat

Quand tu tweak une UI, il y a une astuce que j'utilise assez souvent,
tu fais tout dans le debugger (ou en mode debugger), tu peux changer ton
code
et voir les effets imm�diatement, tant que tu changes juste le code et
pas la hi�rarchy des classes,
et cela r�duit drastiquement le temps de dev.

R�mi

>
> Le 19 juin 2012 � 15:12, Nicolas Labrot a �crit :
>
>> C'est qu'il n'est pas bien foutu si le ROI est proche de z�ro. ;)
>>
>> 2012/6/19 David Screve <david....@gmail.com
>> <mailto:david....@gmail.com>>

>>
>> Sous iOS, ya un framework de test unitaire de GUI assez bien
>> foutu....mais personne ne s'en sert parce que justement, le ROI est

>> proche de z�ro par rapport � un vrai utilisateur.

>>
>> On 18 juin, 22:22, Patrice Trognon <ptrog...@gmail.com

>> <mailto:ptrog...@gmail.com>> wrote:
>> > Le 18 juin 2012 � 19:31, Emmanuel L�charny a �crit :
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > Le 6/18/12 6:30 PM, Altus34 a �crit :
>> > >> 2012/6/18 Emmanuel L�charny<elecha...@gmail.com
>> <mailto:elecha...@gmail.com>>
>> >
>> > >>> Je ne vois toujours pas comment tu v�rifies que ton appli
>> t'affiche bien
>> > >>> toutes les donn�es que tu attends,
>> >
>> > >> C'est ce que je nomme un test d'�cran (cf test cas 2)
>> >
>> > >> quand par exemple ton appli est �crite en SWT, en Swing, etc...

>> >
>> > >> Tu gardes le meme test et tu change de cartouche on a une
>> cartouche Html4
>> > >> mais aussi du Flex en beta qui tourne pour du SWT ou Swing
>> il faudrait

>> > >> l'�crire
>> > > On est bien d'accord : en fait, testatoo g�re du test de web
>> UI, pas d'autre chose (sauf Flex). La *grosse* diff�rence, c'est
>> qu'en HTML, tu peux te parser le HTML et v�rifier qu'il contient

>> bien ce que tu attends par pattern matching ou autre. Sur une
>> GUI, swing ou SWT ou cocoa, bon courage ! Il faut soit trapper

>> les events, soit se taper les �cran, avec tous les pb que �a

>> pose. En RCP, il y a un truc qui s'appelle SWTBot
>> (http://www.eclipse.org/swtbot/) mais c'est franchement

>> sp�cifique. Visiblement, il y a d'autres outils (Sikuli) pour
>> d'autres environnements.
>> >
>> > > La GUI, c'est pas super simple � tester ! Vivement qu'on
>> arr�te de faire de la GUI pure et qu'on s'appuie syst�matiquement
>> sur un moteur de pr�sentation style webKit... C'est marrant,
>> d'ailleurs, du temps de X11, faire des tests unitaires d'�cran
>> aurait �t� assez simple, puisque les affichages �taient g�r�s par
>> le terminal mais en traitant un format de pr�sentation bien
>> d�finit. R�gression ?

>> >
>> > tu pouvais surtout poster assez simplement les evt X11 et donc

>> rejouer un sc�nario, idem sur windows j'avais du code qui faisait
>> �a sous windows 3.1
>> > ca marchait nickel, suffisait de choper les HWND des diff�rents

>> elements et ensuite de leur poster les messages WM_, ils y
>> voyaient que du feu.
>> >

>> > Sur un Swing vu que tout est g�r� par la VM .... je ne sais pas.
>> > sur Mac y'a bien des solutions pour enregistrer un sc�nario et
>> le rejouer, mais bon pour ce que j'ai pu tester cela d�raille

>> assez vite.
>> >
>> > Pat
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > --
>> > > Regards,
>> > > Cordialement,

>> > > Emmanuel L�charny
>> > >www.iktek.com <http://www.iktek.com/>
>> >
>> > > --
>> > > Vous recevez ce message, car vous �tes abonn� au groupe
>> Google Groupes lescastcodeurs.
>> > > Pour envoyer un message � ce groupe, adressez un e-mail �
>> lescast...@googlegroups.com
>> <mailto:lescast...@googlegroups.com>.
>> > > Pour vous d�sabonner de ce groupe, envoyez un e-mail �
>> l'adresse lescastcodeur...@googlegroups.com
>> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.

>> > > Pour plus d'options, consultez la page de ce groupe
>> :http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>> --

>> Vous recevez ce message, car vous �tes abonn� au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message � ce groupe, adressez un e-mail �
>> lescast...@googlegroups.com
>> <mailto:lescast...@googlegroups.com>.
>> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
>> lescastcodeur...@googlegroups.com
>> <mailto:lescastcodeurs%2Bunsu...@googlegroups.com>.

>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>>
>>
>> --

>> Vous recevez ce message, car vous �tes abonn� au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message � ce groupe, adressez un e-mail �
>> lescast...@googlegroups.com <mailto:lescast...@googlegroups.com>.
>> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse
>> lescastcodeur...@googlegroups.com
>> <mailto:lescastcodeur...@googlegroups.com>.

>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>
> --

> Vous recevez ce message, car vous �tes abonn� au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message � ce groupe, adressez un e-mail
> � lescast...@googlegroups.com.
> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse

[David Screve]

On 19 juin, 15:48, Nicolas Delsaux <nicolas.dels...@gmail.com> wrote:
> 2012/6/19 Patrice Trognon <ptrog...@gmail.com>:

>

>
> Et donc, pour vérifier ça, tu préfères examiner une fois l'interface à
> la main avec un inspecteur (si tant est que ça existe dans cet
> environnement ... spécifique), ou écrire le test unitaire qui
> correspond pile poil à ta vérification manuelle et l'exécuter en
> intégration continue (je sais déja ce que je répondrais, hein).
>
> En fait, sous le troll, ce que je questionne, c'est la perception de
> la difficulté.
> Qu'est-ce qui fait, selon toi, que c'est compliqué de vérifier
> (d'après un patron éventuellement - c'est-à-dire un lancement manuel
> avec extraction de l'arbre des propriétés des widgets) que les widgets
> ont bien les propriétés que tu souhaite qu'ils ont de manière
> automatique (et donc vérifiant la non-régression) ?

Ben je ne vois pas l'intérêt ni comment on écrit du code qui vérifie
que c'est moche ou beau ????
Parce que les IHM, c'est souvent ça.....
Si le rendu d'une image est mal foutu, c'est pas franchement
vérifiable par test unitaire....

David

> --
> Nicolas Delsaux

[David Screve]

+1000

On 19 juin, 15:43, Patrice Trognon <ptrog...@gmail.com> wrote:
> héhé, bien joué Nicolas :)
>
> Je pense que c'est plus culturel en fait, dans l'UI c'est tellement long et chiant à développer pour des résultats pas forcement intéressant.
>
> Comme je disais dans une autres réponse j'aurai tendance à limiter les TU/TI au code métier, le reste est testé humainement.
>
> de toute façon le test d'UI, et c'est justement la dedans que je suis cette semaine, cela tourne vite a vérifier si y'a pas une putain
> ligne de 1 point d'épaisseur qui apparait a gauche parce que l'objet de l'image de fond est mal positionné, et ça mis a part lancer
> et faire tourner pour vérifier que tous les objets sont bien alignés, proportionnés, avec les mêmes fontes, etc etc....
>
> Pat
>
> Le 19 juin 2012 à 15:12, Nicolas Labrot a écrit :
>
>
>
>
>
>
>
> > C'est qu'il n'est pas bien foutu si le ROI est proche de zéro. ;)
>

> > 2012/6/19 David Screve <david.scr...@gmail.com>

[Patrice Trognon]

ah ben tu m'expliques comment tu vas développer ce genre de test sur ios :
verifier que tel ou tel objet est positionné au bon endroit, avec les bonnes
proportions, que les paramètres d'affichages sont les bons, que la fonte est la
bonne, avec la bonne taille, que l'animation que tu as placé est bien synchro avec
l'evenement déclenché, etc etc.

franchement je suis preneur hein !

derrière le troll a mon avis tu n'as pas du faire beaucoup d'ui sur cocoa ou ios !

Pat


>
> --
> Nicolas Delsaux

[Nicolas Delsaux]

2012/6/19 Patrice Trognon <ptro...@gmail.com>:

>
>
> derrière le troll a mon avis tu n'as pas du faire beaucoup d'ui sur cocoa ou ios !
>

Non,c 'est vrai.
C'est bien pour ça que je pose la question.
Dans les mondes que je connais un peu (Flex) ou pas mal (Swing), un
écran/scène est représenté par une hérarchie d'objets dont tu peux
inspecter les propriétés. C'est pas toujours le code le plus propre du
monde qui navigue là-dedans, mais t'arrive quand même assez souvent à
vérifier qu'un widget donné a la propriété définie à la valeur que tu
souhaite.
Si ça n'est pas le cas dans iOS, c'est clair, c'est moche.
Mais si c'est le cas ... Rien ne t'empêche de l'utiliser directement
(un test unitaire à la FEST-Assert) ou indirectement (à la Sikuli).
Après, évidement, il y des histoires toujours tordues de compromis sur
ce que tu acceptes de ne pas tester, mais c'est un sujet qui sort un
peu du scope de la ML, non ?

--
Nicolas Delsaux

[Baptiste MATHUS]

Le 19 juin 2012 15:03, "Thibaud Vibes" <thibau...@wanadoo.fr> a écrit :
>
> Le 19/06/2012 14:41, Antonio Goncalves a écrit :
>

>> Ah, le syndrome "Not Invented Here" est de retour. C'est surement du à mon grand age, une fois de plus, mais je n'ai plus la prétention de développer un driver JDBC ou un connecteur transactionnel mieux que les librairies qui existent depuis 10 ans. Je ne développe pas d'APIs mais des applications pour mes clients. Je suis donc content d'utiliser un fwk d'injection plutôt que de réinventer le mien.... mais c'est certainement du à mon grand age... ou à la ribambelle de projets par lesquels je suis passé qui avait "développé leur propre ORM (car Hibernate c'est pourri) mais les développeurs ont quitté la boite".
>>
>> Antonio
>

> +1

+1.
Le NIH est un symptôme trop répandu.
J'ai tendance à penser qu'aujourd'hui si quelqu'un propose une prestation sans utiliser aucun* framework connu, il faut FUIR dans 99% des cas. Non pas pour céder à la mode, mais juste parce que ces fwk sont éprouvés.

(* ne me faites pas dire "tous" il faut trouver le curseur et ne pas choisir le fwk avant le besoin ;)).

[Patrice Trognon]

Le 19 juin 2012 à 16:03, Nicolas Delsaux a écrit :

> 2012/6/19 Patrice Trognon <ptro...@gmail.com>:
>>
>>
>> derrière le troll a mon avis tu n'as pas du faire beaucoup d'ui sur cocoa ou ios !
>>
> Non,c 'est vrai.
> C'est bien pour ça que je pose la question.
> Dans les mondes que je connais un peu (Flex) ou pas mal (Swing), un
> écran/scène est représenté par une hérarchie d'objets dont tu peux
> inspecter les propriétés. C'est pas toujours le code le plus propre du
> monde qui navigue là-dedans, mais t'arrive quand même assez souvent à
> vérifier qu'un widget donné a la propriété définie à la valeur que tu
> souhaite.

on va faire simple, l'introspection t'oublie, et le xml y'en a pas, du moins si mais
on ne le vois pas il est fermé et compilé en binaire sur la cible.

> Si ça n'est pas le cas dans iOS, c'est clair, c'est moche.
> Mais si c'est le cas ... Rien ne t'empêche de l'utiliser directement
> (un test unitaire à la FEST-Assert) ou indirectement (à la Sikuli).
> Après, évidement, il y des histoires toujours tordues de compromis sur
> ce que tu acceptes de ne pas tester, mais c'est un sujet qui sort un
> peu du scope de la ML, non ?
>

yep,enfin ca reste dans la techno donc tout de même un peu.

mais bon, les merdouilles à gerer c'est vraiment des petits soucis de rendu
a cause de différences entre 3gs/4/4s, ios4 et ios5 (demain ios6), bref impossible
à tester automatiquement.

actuellement je porte une applie que j'ai ecrit sur iphone vers ipad, et mes journées
sont occupées par ce genre de petites betises.

Pour illustrer souvent un 'client' me dit : ouaih mais regarde en bidouillant ainsi, justement
dans la hiérarchie des objets, on pourrait faire ce qu'on veut alors que ce n'est pas prévu
dans l'api. mais justement je le décourage d'aller dans ce sens car si la hiérarchie des objets
change cela devient du code glissant à maintenir.

maintenant l'idée c'est pas de coder ses UI mais de les faire entièrement à la souris

pat

[mjoets]

>
> Et franchement, devoir mocker 50 classes pour pouvoir faire son test
> unitaire, là je dis stop: on regarde le code et on refactore...
>
Ben voilà ! le TU vient de te faire refactorer plus proprement du
code, c'est un de ses objectifs et dans ce cas c'est réussi, non ?

[David Screve]

Du coup, j'aurais bien un autre troll, mais je vais attendre
dredi..... :-)

David

[Emmanuel Lécharny]

Le 6/19/12 4:07 PM, Baptiste MATHUS a écrit :

"Eprouvés"* ??? Simplement parceque des millions de crétins collent du
Spring/Hibernate/Memcached/choisittonframeworkdemerde dans leurs
propales, sinon ça passe pas le comité de lecture des MOA qui de toutes
façon n'y comprennent rien ?

Je veux bien que ces frameworks sont bien écrit, le problème est que :
1) 99% des utilisateurs n'en comprennent que 5%
2) 99% des utilisateurs n'en ont pas besoin mais sont de tels moutons
qu'ils pensent que ces framreworks sont indispensables
3) 99% des utilisateurs n'en utilisent que 5%, au mieux...

Au final, tu ferais une propale sans framework, ça ne se verrait pas en
conception.

Finalement, l'idéal est de faire une propale en indiquant que tu les
utilises, mais en fait, tu les mets dans un coin bien discret pour que
personne te demande où ils sont dans ton code. Ni vu, ni connu,
j't'embrouille la MOA !

Bon bien sûr, comme d'hab, j'exagère. Mais posez vous au moins la
question de savoir ce que les frameworks qui vous êtes censés utiliser
résolvent comme problème, et le temps que cela représente, par rapport
aux problèmes que vous rencontrez quand vous y avez recours (bien sûr,
vous intégrerez les problèmes de vos padawans qui découvrent ces
frameworks et qui vous pondent des étrons bien fumant...)

[Pierre-Yves Ricau]

Le 19 juin 2012 18:43, Emmanuel Lécharny <elec...@gmail.com> a écrit :

Le 6/19/12 4:07 PM, Baptiste MATHUS a écrit :

Bah, l'avantage là, c'est que le padawan, s'il fait bien son boulot, il va perdre du temps à apprendre le framework "une seule fois". Si t'as ton monstre maison, bah... ça ne reservira pas :) . Ça fait que du coup, t'as plus de padawan sur le marché qui savent comment ça marche. Ce qui arrange bien tout le ptit monde des SSII et des rotations de mission annuelle :) .

Jsais pas vous, mais jsuis quand même bien content de pouvoir utiliser un framework json, un framework de sécurité, un framework pour OAuth / toutes les putains de couches sociales qui ont chacune leur propre custom d'OAuth..

 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Pierre-Yves Ricau

http://www.piwai.info

[Emmanuel Lécharny]

Le 6/19/12 7:12 PM, Pierre-Yves Ricau a écrit :

> Le 19 juin 2012 18:43, Emmanuel Lécharny<elec...@gmail.com> a écrit :
>
>> Le 6/19/12 4:07 PM, Baptiste MATHUS a écrit :
>>

>> Le 19 juin 2012 15:03, "Thibaud Vibes"<thibaud.vibes@wanadoo.**fr<thibau...@wanadoo.fr>>

>>> a écrit :
>>>
>>>> Le 19/06/2012 14:41, Antonio Goncalves a écrit :
>>>>
>>>> Ah, le syndrome "Not Invented Here" est de retour. C'est surement du à
>>>> mon grand age, une fois de plus, mais je n'ai plus la prétention de
>>> développer un driver JDBC ou un connecteur transactionnel mieux que les
>>> librairies qui existent depuis 10 ans. Je ne développe pas d'APIs mais des
>>> applications pour mes clients. Je suis donc content d'utiliser un fwk
>>> d'injection plutôt que de réinventer le mien.... mais c'est certainement
>>> du
>>> à mon grand age... ou à la ribambelle de projets par lesquels je suis
>>> passé
>>> qui avait "développé leur propre ORM (car Hibernate c'est pourri) mais les
>>> développeurs ont quitté la boite".
>>>
>>>> Antonio
>>>> +1
>>>>
>>> +1.
>>> Le NIH est un symptôme trop répandu.
>>> J'ai tendance à penser qu'aujourd'hui si quelqu'un propose une prestation
>>> sans utiliser aucun* framework connu, il faut FUIR dans 99% des cas. Non
>>> pas pour céder à la mode, mais juste parce que ces fwk sont éprouvés.
>>>
>> "Eprouvés"* ??? Simplement parceque des millions de crétins collent du

>> Spring/Hibernate/Memcached/**choisittonframeworkdemerde dans leurs

>> propales, sinon ça passe pas le comité de lecture des MOA qui de toutes
>> façon n'y comprennent rien ?
>>
>> Je veux bien que ces frameworks sont bien écrit, le problème est que :
>> 1) 99% des utilisateurs n'en comprennent que 5%
>> 2) 99% des utilisateurs n'en ont pas besoin mais sont de tels moutons
>> qu'ils pensent que ces framreworks sont indispensables
>> 3) 99% des utilisateurs n'en utilisent que 5%, au mieux...
>>
>> Au final, tu ferais une propale sans framework, ça ne se verrait pas en
>> conception.
>>
>> Finalement, l'idéal est de faire une propale en indiquant que tu les
>> utilises, mais en fait, tu les mets dans un coin bien discret pour que
>> personne te demande où ils sont dans ton code. Ni vu, ni connu,
>> j't'embrouille la MOA !
>>
>> Bon bien sûr, comme d'hab, j'exagère. Mais posez vous au moins la question
>> de savoir ce que les frameworks qui vous êtes censés utiliser résolvent
>> comme problème, et le temps que cela représente, par rapport aux problèmes
>> que vous rencontrez quand vous y avez recours (bien sûr, vous intégrerez
>> les problèmes de vos padawans qui découvrent ces frameworks et qui vous
>> pondent des étrons bien fumant...)
>
> Bah, l'avantage là, c'est que le padawan, s'il fait bien son boulot, il va
> perdre du temps à apprendre le framework "une seule fois". Si t'as ton
> monstre maison, bah... ça ne reservira pas :) .

Je n'ai jamais parlé d'avoir un "monstre" maison ! La plupart du temps,
se taper du framework, c'est juste apprendre qq chose pour rien.

Après NoSQL, NoFramework !

Maintenant, attention, il s'agit de s'entrendre sur la notion de
framework. JDBC, Servlet, etc, ce ne sont pas des frameworks. Ce sont
des APIs. Log4j n'est pas non plus un framework. Quand tu parles de
framework JSon, pour moi, c'est d'abord et avant tout une API dont il
s'agit.

Un framework, c'est quand même plus large.

[Thibaud Vibes]

JUnit?
(bon ok je charie)

[Cédric Beust ♔]

2012/6/19 Thibaud Vibes <thibau...@wanadoo.fr>

Un framework, c'est quand même plus large.

JUnit?

On ne plaisante pas avec ça.

-- 

Cédric

[Baptiste MATHUS]

Mina alors ? Ou pire, Netty ?

>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Patrice Trognon]

+1
Franchement ça me fait chaud au coeur de constater que ce que je pense depuis plus de 5 ans fait son chemin !
L'utilisation d'un framework c'est comme pour les optimisations des perfs, si le gain est inférieur à 10% il faut se poser la question de la réécriture maison, remonter des mégas de jars pour une toute petite feature c'est du délire ! Surtout que souvent au passage en bon concepteur objet on va faire du faible couplage pour cette intégration donc écrire du code de glue, ben autant écrire directement la feature nécessaire.

J'ai commencé à prendre ce réflexe quand ça m'a gonflé de voir le nombre de jars exploser pour faire hello world, c'était un signe que quelque chose clochait et la bonne réponse à mes yeux n'était pas de faire un pom.xml ! Le collègue m'a forcé à coller ce truc dans la partie java de notre projet ben putain j'aurai du résister, qu'elle merde.

Vive le NoFramework, je veux me joindre à ton mouvement de fond Emmanuel :)

>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

[Nicolas Labrot]

Généralement le framework n'est pas la pour une "feature". Si effectivement tu utilises un framework pour une feature, je pense que le problème est la, moins dans le framework mal utilisé ;)

2012/6/19 Patrice Trognon <ptro...@gmail.com>

[Jeff MAURY]

Personnellement, je ne vois la chose tout à fait de la même manière : je pense que la distinction que fait Manu entre API et framework l'arrange bien.
Il me semble plutôt qu'il y a des frameworks qui se concentrent sur une seule chose (genre Hibernate) et d'autres qui ont tendance à vouloir refaire le monde (Spring): c'est sur que prendre Spring pour faire du DI, c'est tout much, il y a plein d'autres outils plus légers qui le font très bien (Guice, PicoContainer,...)
Donc je pense que si un framework fournit une valeur ajoutée bien identifiée et cernée, alors cela fait sens.

A+
Jeff
 

2012/6/19 Patrice Trognon <ptro...@gmail.com>

--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

[Nicolas Labrot]

Cette comparaison entre Hibernate qui ne fait qu'une seule chose et Spring qui refait le monde est intéressante. Personnellement j'aurais inversé.

2012/6/19 Jeff MAURY <jeff...@jeffmaury.com>

[David Screve]

On 19 juin, 21:34, Nicolas Labrot <nith...@gmail.com> wrote:
> Cette comparaison entre Hibernate qui ne fait qu'une seule chose et Spring
> qui refait le monde est intéressante. Personnellement j'aurais inversé.
>

Un exercice intéressant pour ceux qui sont fan du duo de choc Spring
+Hibernate : amusez vous a l'utiliser avec Wicket et Vaadin en
essayant de conserver toute la gestion transactionnelle de
Hibernate.....acharnez vous 1 ou 2 semaines et vous verrez que dans ce
contexte, non seulement ça ne sert à rien, mais en plus ça donne du
boulot en plus...du coup, comme je n'aime pas me palucher des jsp à la
mimine, ben j'ai mis de côté....

Autre activité amusante pour les hibernatiens, essayez une vraie base
de données objet et aller voir du côté de CoreData...vous verrez, ça
ça vous changer votre vision du monde.....

David

[Emmanuel Lécharny]

Le 6/19/12 8:06 PM, Baptiste MATHUS a écrit :

> Le 19 juin 2012 19:46, "Emmanuel Lécharny"<elec...@gmail.com> a écrit :
>
>> Un framework, c'est quand même plus large.
> Mina alors ? Ou pire, Netty ?

Non. Ce sont juste des frameworks NIO, et rien de plus. Leur portée est
extrèmement limitée.

Comme je le disais, il faut distinguer ce qui relève de l'outillage
utile des frameworks qui sont censés te faire papa maman. Personne ne va
récuser des ourils comme Log4j (et ses avatars variés) ou JUnit, qui
relèvent de l'outillage indispensable.

Le problème, c'est quand tu interviens en support sur des projets où les
mecs font une telle utilisation d'un truc comme Spring qu'à un moment,
tu passes juste plus de temps à compulser des fichiers XML pour
comprendre l'enchaînement des beans qu'à regarder du code... Là, on est
déjà dans le tripotage de bits façon équipe de France de foot, au lieu
d'aller droit au but.

Après, ça pose la question de savoir ce que tu testes : le framework, ou
ton code ? Et on rentre dans un débat qui consiste à savoir s'il est
utile de faire des tests unitaire tout court...

[Emmanuel Lécharny]

Le 6/19/12 9:25 PM, Jeff MAURY a écrit :

> Personnellement, je ne vois la chose tout à fait de la même manière : je
> pense que la distinction que fait Manu entre API et framework l'arrange
> bien.

Bien sûr ! Après, le pb est de savoir ce qui relève du simple outil et
ce qui relève du framework. Le curseur peut être positionné comme on veut.

> Il me semble plutôt qu'il y a des frameworks qui se concentrent sur une
> seule chose (genre Hibernate) et d'autres qui ont tendance à vouloir
> refaire le monde (Spring): c'est sur que prendre Spring pour faire du DI,
> c'est tout much, il y a plein d'autres outils plus légers qui le font très
> bien (Guice, PicoContainer,...)

Picocontainer est peut-êre le plus sous-estimé outil de DI !

> Donc je pense que si un framework fournit une valeur ajoutée bien
> identifiée et cernée, alors cela fait sens.

Oui. Il faut aussi le maîtriser, ce qui n'est pas facile.

Bien sûr qu'un framework a son utilité, mais encore faut-il comprendre
sa portée, et ses limites.

[Nicolas Labrot]

2012/6/20 Emmanuel Lécharny <elec...@gmail.com>

Le 6/19/12 8:06 PM, Baptiste MATHUS a écrit :

Le 19 juin 2012 19:46, "Emmanuel Lécharny"<elec...@gmail.com>  a écrit :

Un framework, c'est quand même plus large.

Mina alors ? Ou pire, Netty ?

Non. Ce sont juste des frameworks NIO, et rien de plus. Leur portée est extrèmement limitée.

Comme je le disais, il faut distinguer ce qui relève de l'outillage utile des frameworks qui sont censés te faire papa maman. Personne ne va récuser des ourils comme Log4j (et ses avatars variés) ou JUnit, qui relèvent de l'outillage indispensable.

Le problème, c'est quand tu interviens en support sur des projets où les mecs font une telle utilisation d'un truc comme Spring qu'à un moment, tu passes juste plus de temps à compulser des fichiers XML pour comprendre l'enchaînement des beans qu'à regarder du code... Là, on est déjà dans le tripotage de bits façon équipe de France de foot, au lieu d'aller droit au but.

Regarder le code ne veut pas dire en soi grand chose, car si c'est regarder des km de code (en remplacement de ces fichiers XML) mal pensé, mal testé la valeur ajouté est nulle.

Je pense que l'on a tous compris que tu n'aimais pas le XML :) et Spring ce n'est pas (plus) que cela. Au demeurant Spring n'est pas le problème, c'est comme d'habitude son utilisation qui peut l'être. Je pourrais remplacer Spring par n'importe quelle autre framework car entre un projet qui réinvente la roue et met en place un code maison à 80% cradingue et mal testé parce que pas le temps, et un projet qui utilise un framework bien pensé, la plus value va vers le second.

[Dimitri]

Pour en revenir au sujet des tests :

Les spécifications (si elles existent !!) sont généralement non vérifiables automatiquement donc vouées à être trahies silencieusement. Donc les tests pris comme des spécifications exécutables me semblent être juste indispensables.

SSLDDC, ou coder sans tests ça veut dire : "Allez fait moi un chèque en blanc et fais moi confiance je vais te faire ce que tu veux. Pas la peine de signer un contrat hein ! Fais moi confiance." Toute ressemblance avec des contrats de service est un pur hasard. 

Vive les tests ! Sortez couverts !

Après si votre stack ou framework ou API est intestable ... il faut peut-être aller voir s'il n'y a pas un endroit plus civilisé et plus sûr. 

La jungle ça amuse Tarzan, mais pas sûr que ça amuse Jane :-)

-------------------------------

Dimitri BAELI

[Nicolas Delsaux]

2012/6/19 Cédric Beust ♔ <ced...@beust.com>:

>
>
>
> On ne plaisante pas avec ça.
>

Meuh non, on sait bien qu'il ne faut pas utiliser jUnit, mais ...
JTestCase ! (http://jtestcase.sourceforge.net/) ou alors ... T2 !
(http://www.cs.uu.nl/wiki/WP/T2Framework)

(n'empêche, trouver un outil de test Java qui ne soit NI jUnit, NI
TestNG, c'est pô facile ... qu'est-ce que je ferais pas pour nourir
une blague).


--
Nicolas Delsaux

[Nicolas Delsaux]

2012/6/20 Dimitri <dba...@gmail.com>:

> Pour en revenir au sujet des tests :
>
> Les spécifications (si elles existent !!) sont généralement non vérifiables
> automatiquement donc vouées à être trahies silencieusement. Donc les tests
> pris comme des spécifications exécutables me semblent être juste
> indispensables.

OUF, enfin un peu de bon sens !

>
> SSLDDC, ou coder sans tests ça veut dire : "Allez fait moi un chèque en
> blanc et fais moi confiance je vais te faire ce que tu veux. Pas la peine de
> signer un contrat hein ! Fais moi confiance." Toute ressemblance avec des
> contrats de service est un pur hasard.

OUF, encore du bon sens.
Je sais pas si c'est la défaite footbalistique ou le soleil qui se
montre enfin, mais ce matin, j'ai eu l'impression de voir des choses
bizarres sur cette ML :

- des victimes consentantes du syndrôme NIH
- des mecs souhaitant refaire leur monde dans leur coin, sans jamais
penser au pauvre type qui fera la fichue maintenance dans 5 ans


Donc je vais rabacher une ou deux évidences (déja lues ici, d'ailleurs).
Si vous faites tout vous même, quand vous quittez votre poste, votre
code devient une boîte noire bonne à jeter.
Et je ne sais pas si c'est aussi vrai chez les SSII, mais chez les
éditeurs de logiciel, le code livré en boîte noire, on le balance dans
les poubelles de l'histoire dès qu'il faut étendre un peu ses
capacités. Du coup, forcément, les frameworks (avec des licences
compatibles avec la vente de logiciels) on aime bien ça.

>
> Vive les tests ! Sortez couverts !

Ah, et en bonus, n'oubliez jamais que vous êtes souvent de moins bons
débuggeurs que développeurs. Du coup, avoir des tests, c'est bien
pratique pour ne pas débugger comme un fou dans un cas client tordu
(ou en tout cas ça permet de le faire moins souvent, et de consacrer
du coup plus de temps à Youtube/aux castcodeurs ... heu, à la
conception de l'usine logicielle)

>
> Après si votre stack ou framework ou API est intestable ... il faut
> peut-être aller voir s'il n'y a pas un endroit plus civilisé et plus sûr.

Ou voir comment le tester.
Parce que souvent, les frameworks sont plus testables que les
applications qu'on développe avec, alors qu'il y a plus de boulot pour
les tester. Paradoxal ? Pas tant que ça.

>
> La jungle ça amuse Tarzan, mais pas sûr que ça amuse Jane :-)
>

J'ai entendu dire que sauter de branche à branche amusait aussi
beaucoup les amateurs de gestionnaires de sources touffus.

--
Nicolas Delsaux

[Emmanuel Lécharny]

Le 6/20/12 8:11 AM, Nicolas Labrot a écrit :

> 2012/6/20 Emmanuel Lécharny<elec...@gmail.com>
>
>> Le 6/19/12 8:06 PM, Baptiste MATHUS a écrit :
>>
>>> Le 19 juin 2012 19:46, "Emmanuel Lécharny"<elec...@gmail.com> a écrit
>>> :
>>>
>>> Un framework, c'est quand même plus large.
>>> Mina alors ? Ou pire, Netty ?
>>>
>> Non. Ce sont juste des frameworks NIO, et rien de plus. Leur portée est
>> extrèmement limitée.
>>
>> Comme je le disais, il faut distinguer ce qui relève de l'outillage utile
>> des frameworks qui sont censés te faire papa maman. Personne ne va récuser
>> des ourils comme Log4j (et ses avatars variés) ou JUnit, qui relèvent de
>> l'outillage indispensable.
>>
>> Le problème, c'est quand tu interviens en support sur des projets où les
>> mecs font une telle utilisation d'un truc comme Spring qu'à un moment, tu
>> passes juste plus de temps à compulser des fichiers XML pour comprendre
>> l'enchaînement des beans qu'à regarder du code... Là, on est déjà dans le
>> tripotage de bits façon équipe de France de foot, au lieu d'aller droit au
>> but.
>>
>
> Regarder le code ne veut pas dire en soi grand chose, car si c'est regarder
> des km de code (en remplacement de ces fichiers XML) mal pensé, mal testé
> la valeur ajouté est nulle.

Ce n'est pas ce que j'ai voulu dire.

En pratique, devoir basculer en permanence entre du XML et du code pour
comprendre un programme, c'est un peu pénible (et je suis dans
l'understatement ici). Et à un moment, framework ou pas framework, tu
devras plonger dans le code de toute façon. Par ailleurs, le code n'est
pas ncessairement un substitut au XML. Il est parfois beaucoup plus
difficile de comprendre une "logique" qui a été dispersée à travrs N
couches par des personnes qui ne maîtrisent pas ces couches que de
simplement rentrer dans le code.

>
> Je pense que l'on a tous compris que tu n'aimais pas le XML :) et Spring ce
> n'est pas (plus) que cela. Au demeurant Spring n'est pas le problème, c'est
> comme d'habitude son utilisation qui peut l'être.

C'est clair que je n'aime pas Spring. Je fréquente cette bouse depuis sa
conception (fin 2002) quand j'avais trouvé que le framework web qu'il
proposait était un peu mieux (moins mal) foutu que struts. J'ai vite
déchanté.

Par ailleurs, on l'a utilisé (à l'insu de mon plein gré) sur le projet
sur lequel je bosse depuis 2005 et on en a chié pendant 5 ans avant de
le virer. Personne, je dit bien personne, sur le projet (ApacheDS) n'a
trouvé que Spring apportait un gain quelconque ni du point de vue
fonctionalité, ni du point de vue lisibilité, au contraire.

Je veux bien qu'on se paluche à coup d'injection de dépendences, mais à
un moment, il faut aussi se poser la question de l'utilité de ce type de
mécanisme. Si tu as une approche modulable, avec points d'extensions, je
pense que Spring n'est pas la bonne réponse. OSGi, malgré sa complxité,
me parait bien plus cohérent et pratique.

En tout cas, à un moment, on en a eu marre d'avoir deux fenêtres
ouvertes pour savoir comment le serveur était initialisé, et qu'au
débuggeur, c'est juste un cauchemard, vu que tu es obligé de mettre des
points d'arrêt dans chacun des constructeurs qui sont invoqués par
Spring. Ca va quand tu as une dizaine de beans, max, mais quand tu
atteints la 50aine, c'est juste impossible.

Pour le reste, j'ai aussi regardé SpingLDAP, et franchement, quand je
regarde le code associé, je me dis que si le reste du framework est
d'aussi mauvaise qualité, et bien faut pas s'étonner d'avoir des
problèmes. (je parle là d'incohérences et de totale méconnaissance des
technos sous-jacentes : les mecs qui avaient pondu cette extension
avaient rajoutés ce qu'ils appelaient des 'transaction' LDAP, ce qui
était totalement incohérent).

Donc, si, Spring est un problème.Son utilisation aussi.

> Je pourrais remplacer
> Spring par n'importe quelle autre framework car entre un projet qui
> réinvente la roue et met en place un code maison à 80% cradingue et mal
> testé parce que pas le temps, et un projet qui utilise un framework bien
> pensé, la plus value va vers le second.

Tu peux faire de la merde en code in-house ou avec un framework. Le
probème n'est pas là. Mon propos est de dire que dans pas mal de cas,
les développeurs ou pire, les architectes, voient dans un framework la
solution magique à leur problèmes. Dans 90% des cas (allez, 95%), c'est
juste se foutre le doigt dans l'oeil jusqu'à l'omoplate.

Après, je ne suis pas contre les frameworks (sauf Spring). Je suis juste
contre l'utilisation aveugle qui en est faite. Vous avez un cerveau,
réflechissez avant de mettre une couche de plâtre qui masque les
fissures de votre architecture !

[Thibaud Vibes]

Le 20/06/2012 09:44, Emmanuel Lécharny a écrit :
> Je veux bien qu'on se paluche à coup d'injection de dépendences, mais
> à un moment, il faut aussi se poser la question de l'utilité de ce
> type de mécanisme. Si tu as une approche modulable, avec points
> d'extensions, je pense que Spring n'est pas la bonne réponse. OSGi,
> malgré sa complxité, me parait bien plus cohérent et pratique.

C'est intéressant. Si on essaye de revenir sur les tests et les
framework allez j'ai 2 questions pour ceux (en espérant ne pas être le
seul) qui ne connaissent pas du tout OSGi :
- Comment ça se passe les tests quand on fait du OSGi ? Je vois à peu
près comment tester son module. Par contre comment teste t-on les modes
dégradés (genre le module A a besoin du module B qui n'est pas chargé ...)
- Peut-on qualifier OSGi de framework ?

[Manu]

Faut arrêter de dire que faire du Spring oblige à faire des tartines de XML par contre.

Avec les annotations, j'ai quasiment plus de XML à produire !

2012/6/20 Emmanuel Lécharny <elec...@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Emmanuel Lécharny]

Le 6/20/12 10:02 AM, Thibaud Vibes a écrit :

C'est à peu près aussi chaud que de tester un projet modulaire où tu
chargerais les composant en live. Non, ce n'est pas simple. Après, tu as
plusieurs niveaux d'utilisation de OSGi.

> - Peut-on qualifier OSGi de framework ?

Je pense, oui. Mais c'est comme MINA, il se limite à gérer le chargement
des bundles, à gérer les dépendences et le cycle de vie, donc pas sûr
qu'il s'agisse d'un framework au sens où on l'entend, comparé à Spring.

[Jean-Laurent de Morlhon]

Écrire des tests ça s'apprends, faut s'entraîner, essayer des trucs parfois qui marchent et parfois qui ne marchent pas. Et au fur et à mesure on sait les écrire sans perdre de temps. Être efficace quoi. 

Un peu comme on cherche à etre efficace avec une stack techno, jee ou spring par exemple. Ça s'apprends. 

Combien de temps vous avez passé à lire la doc des embedded ou des one-to-many dans hibernate ou les variations de @transactional dans spring plutôt que @Rule ou @Spy. 

Et c'est la que le bas blesse. C'est plus cool et vendeur sur le marché de dire qu'on maîtrise tel ou tel framework que de dire que l'on sait tester. 

Le développeur et en particulier le développeur java, préfère et de loin s'amuser à potasser et entasser 3 tonnes de frameworks plutôt que de passer 10 minutes à apprendre à tester. Peut être que c'est la courbe d'apprentissage globale qui amène à savoir manipuler un framework puis d'apprendre à tester.

Notre job c'est de de faire des les 2 coder & tester l'un sans l'autre c'est ... le truc cité dans le marais d'Emmanuel quoi ;)

-- Jean-Laurent

[Emmanuel Lécharny]

Le 6/20/12 10:03 AM, Manu a écrit :

> Faut arrêter de dire que faire du Spring oblige à faire des tartines de XML
> par contre.
> Avec les annotations, j'ai quasiment plus de XML à produire !

C'est encore pire. Maintenant, tu te tartines des tonnes d'annotations
partout pour savoir ce qui se passe, au lieu d'avoir une vision globale.

Been there, done that. Conclusion, c'est de la merde en barre de 10.

Par ailleurs, ça mériterait un autre thread un dredi : quand
cessera-t-on de balancer des annotations absolument partout dans le code
? A un moment, ça devient juste un langage supplémentaire à apprendre,
sans compter les collisions d'annotations quand on utilise plusieurs
outils avec annotations...

les seules que je trouve à peu près utiles sont les annotations de JUnit
(et celles qui permettent de faciliter les tests)
Ah, j'oubliais : @Override est utile ;-)

[Guillaume Sauthier]

Pour les test unitaires, il n'y a aucune différences car on les execute (forcément) hors conteneur OSGi, on mocke, on assert, c'est tout pareil.

Pour les tests d'intégration (bref, où on lance un conteneur OSGi), il y a des outils pour ca: pax-exam, junit4osgi, testng4osgi, ...

Ces outils te permettent de configurer les bundles que tu lances sur ta passerelle, afin de fournir un environnement d'execution maitrisé pour tes tests.

Ensuite, lors des tests, tu peux, à loisir (et en fonction des capacités de ton modele à composant), tester le dynamisme de ton application en activant/désactivant des composants.

Habituellement, on ne teste pas les dépendences du genre "Bundle A a besoin de classes de Bundle B, mais Bundle B n'est pas chargé", car c'est le conteneur OSGi lui-meme qui va lever une exception à l'installation du Bundle A en spécifiant qu'une dépendence n'a pas été satisfaite, bref, ton Bundle A n'est meme pas chargé.

--Guillaume

 

- Peut-on qualifier OSGi de framework ?

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Pierre-Yves Ricau]

Le 20 juin 2012 10:26, Emmanuel Lécharny <elec...@gmail.com> a écrit :

Le 6/20/12 10:03 AM, Manu a écrit :

Faut arrêter de dire que faire du Spring oblige à faire des tartines de XML
par contre.
Avec les annotations, j'ai quasiment plus de XML à produire !

C'est encore pire. Maintenant, tu te tartines des tonnes d'annotations partout pour savoir ce qui se passe, au lieu d'avoir une vision globale.

Been there, done that. Conclusion, c'est de la merde en barre de 10.

Par ailleurs, ça mériterait un autre thread un dredi : quand cessera-t-on de balancer des annotations absolument partout dans le code ? A un moment, ça devient juste un langage supplémentaire à apprendre, sans compter les collisions d'annotations quand on utilise plusieurs outils avec annotations...

En forme en ce moment, tu mitrailles dans tous les sens :) . "A un moment, ça devient juste un langage supplémentaire à apprendre" : au même titre qu'une lib quelconque.. dès que tu ajoutes des choses, bah tu as plus de choses à apprendre... est-ce étonnant ?

Pour le côté "collision d'annotations", c'est le même genre de problèmes qu'avec l'AOP, sauf qu'au moins là tu sais qu'il peut se passer quelque chose, ya un indice :) . C'est aussi l'éternelle question de l'utilisation de libs pas forcément pensées pour bosser ensemble, et ce qui fait parfois de nous des "intégrateurs" plutôt que des "créateurs".

On peut bacher tout ce qu'on veut sur les annotations, je trouve quand même que c'est hyper intéressant dès qu'on y ajoute un annotation processor, parce que ça permet de faire de la validation à la compilation, en ajoutant des erreurs de compil ou des warnings. Un peu comme le @Override, tes annotations ne servent pas juste à donner une info, elles te permettent de détecter des erreurs. Bon, malheureusement, l'annotation processing reste très peu utilisé.

 

les seules que je trouve à peu près utiles sont les annotations de JUnit (et celles qui permettent de faciliter les tests)
Ah, j'oubliais : @Override est utile ;-)

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr