Quel framework de mock utilisez vous et pourquoi ?

[Denis Sanchez]

Bonjour à tous

j'ai utilisé mockito et jmock comme framework de mock en environemment java. Et vous vous utilisez quoi?

Quel est pour vous le plus simple d'utilisation et qui répond au mieux à vos besoins.

Merci pour vos retours.

Denis SANCHEZ
Edition - Informatique opérationnelle
VIF
Tél. +33 (0)2 51 89 12 40
Fax +33 (0)2 51 89 12 79
denis....@vif.fr
www.vif.fr

[Marc Gabriel-Willem]

Bonjour,

J'avoue beaucoup aimer la simplicité de Mockito.
De plus, celui-ci répond à tous mes besoins.

Cordialement,
Marc

2012/7/18 Denis Sanchez <denis....@vif.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

[David Screve]

Tiens, simple curiosité, je me demande comment vous feriez le mock
d'un serveur SCEP ?

David

On 18 juil, 16:12, Denis Sanchez <denis.sanc...@vif.fr> wrote:
> Bonjour à tous
> j'ai utilisé mockito et jmock comme framework de mock en environemment
> java. Et vous vous utilisez quoi?
> Quel est pour vous le plus simple d'utilisation et qui répond au mieux à
> vos besoins.
> Merci pour vos retours.
>

> *Denis SANCHEZ*
> Edition - Informatique opérationnelle
> *VIF*

> Tél. +33 (0)2 51 89 12 40
> Fax +33 (0)2 51 89 12 79

> denis.sanc...@vif.frwww.vif.fr

[Moandji Ezana]

2012/7/18 Denis Sanchez <denis....@vif.fr>

Et vous vous utilisez quoi?

Quel est pour vous le plus simple d'utilisation et qui répond au mieux à vos besoins.

Mockito : simple et pas surpuissant.

Moandji

[Emmanuel Bernard]

Je n'utilise pas d'outil de mock.

Un peu dans cette philosophie http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/

2012/7/18 Denis Sanchez <denis....@vif.fr>

--

[Jean-Sébastien FRANCK]

Ne pas utiliser d'outil de mock, n'est ce pas violer le principe du test unitaire? A savoir qu'il faut uniquement tester le code de la classe cible, indépendamment du fonctionnement des autres classes.

En ce qui me concerne j'utilise EasyMock. Je crois savoir que les mock de Mockito sont tous des nice mock (si le comportement du mock n'est pas précisé, une valeur par défaut est renvoyée) et je trouve ça un peu dangereux. Par exemple si vous testez une couche business et vous moquez un accès à un DAO, EasyMock fait planter le test si vous n'avez pas précisé le comportement attendu de tout appel au DAO. Alors que ça ne pose pas de problème à Mockito. Si vous rajoutez donc dans votre code métier un dao.create(...), rien ne vous garantit que vos TU couvrent ce cas. Ok ok ça n'arriverait pas dans une démarche TDD, mais le but des TU reste d'éviter les régressions. A noter que ce comportement d'EasyMock est celui par défaut, il est possible de créer des nice mocks.

[Emmanuel Bernard]

2012/7/18 Jean-Sébastien FRANCK <jsebf...@gmail.com>

Ne pas utiliser d'outil de mock, n'est ce pas violer le principe du test unitaire? A savoir qu'il faut uniquement tester le code de la classe cible, indépendamment du fonctionnement des autres classes.

Mon objectif c'est de tester mon appli ou ma librairie, pas de faire plaisir au mec qui a inventé la définition des test unitaires. Donc après si je froisse des unitistes, ça ne va pas m'empêcher de dormir.

La question plus intéressante, c'est en quoi les arguments de Bill sont invalides, si ils le sont et dans quels cas utiliser des mocks vs une couche légère mais complète.

[David Screve]

On 18 juil, 20:31, Jean-Sébastien FRANCK <jsebfra...@gmail.com> wrote:
> Ne pas utiliser d'outil de mock, n'est ce pas violer le principe du test
> unitaire? A savoir qu'il faut uniquement tester le code de la classe cible,
> indépendamment du fonctionnement des autres classes.

Je retourne la question : Utiliser un outil de Mock pour faire un test
unitaire, ce n'est pas cacher un test d'intégration dans un test
unitaire ?

David

[ehsavoie]

Quand tu ne peux pas utiliser une couche légère et complète : ca sert
plus de stub que de mock mais avec du code ancien qui depend de
conteneurs 'lourds' c'est bien utile.
Ca sert aussi quand tu as du code qui n'a pas été pensé pour être
testé ou testble et que tu veux reduire le contexte à mettre en place
pour le tester avant de le refactorer.
Bref quand tu pleures dans du legacy le mock est ton ami
----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie


2012/7/18 David Screve <david....@gmail.com>:

[David Screve]

Je suis tout à fait d'accord....c'était juste pour éveiller les
esprits du "Je mock systématiquement".....Parce que le Mock ne permet
en aucun cas de tester les cas aux limites sur des dispositifs
matériels, ou du moins pas en totalité (vas mocker un
accéléromètre...)

David

On 18 juil, 20:55, ehsavoie <emmanuel.hugon...@gmail.com> wrote:
> Quand tu ne peux pas utiliser une couche légère et complète : ca sert
> plus de stub que de mock mais avec du code ancien qui depend de
> conteneurs 'lourds' c'est bien utile.
> Ca sert aussi quand tu as du code qui n'a pas été pensé pour être
> testé ou testble et que tu veux reduire le contexte à mettre en place
> pour le tester avant de le refactorer.
> Bref quand tu pleures dans du legacy le mock est ton ami
> ----------
> Emmanuel Hugonnethttp://www.ehsavoie.comhttp://twitter.com/ehsavoie
>

> 2012/7/18 David Screve <david.scr...@gmail.com>:

[Julien Vermillard]

Bill Burke, celui-là toujours à troller sans connaitre le fond du sujet :)

Effectivement ne pas faire de test d'intégration (tester ton appli
avec toutes la stack de démarrée) c'est une bétise. Par contre en
déduire que les tests unitaires à base de mock sont une escroquerie,
ca tiens du troll.

Comment teste tu tous les cas où tu peux avoir des IOException dans
ton code sans mock ? tous les cas ou l'API est violé et un null est
passé comme argument ? Effectivement tu va bien tester ton appli avec
des tests d'intégration lourd, mais le test untaire n'est pas là pour
ça. C'est plutôt pour mettre au point le code et ratisser toutes le
parties difficile à reproduire et à tester.

Comme d'hab il mélange deux chose différente et les oppose pour créer un troll.

Julien

2012/7/18 Emmanuel Bernard <emma...@lescastcodeurs.com>:

[Patrice Trognon]

a quoi bon t'emmerder avec des tests unitaires si tes tests fonctionnels couvrent l'ensemble du domaine ?

ce que j'ai pu constater c'est que quand le client accepte de payer uniquement les tests unitaires il reste plein de merdes,
alors que quand le client nous a dit de ne pas faire de tests unitaires parce qu'il développait lui des tests fonctionnels on
n'avait quasiment aucun soucis en sorti de validation.

de la a en conclure que les tests unitaires ne servent a rien si on a une bonne couverture de tests fonctionnels on
peut le penser non ?

Pat

[Julien Vermillard]

Tu peux toujours t'en passer, tu va jute te priver d'un outil utile
pour couvrir à fond certaine parties du code.

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

[Patrice Trognon]

bof, deja largement débattu j'ai déjà expliqué comment je fonctionne, les TU je m'en passe depuis longtemps/toujours
avec mon couple debugger + tests fonctionnels

Pat

[Jeff MAURY]

2012/7/18 Julien Vermillard <jverm...@gmail.com>

Bill Burke, celui-là toujours à troller sans connaitre le fond du sujet :)

Effectivement ne pas faire de test d'intégration (tester ton appli
avec toutes la stack de démarrée) c'est une bétise. Par contre en
déduire que les tests unitaires à base de mock sont une escroquerie,
ca tiens du troll.

Comment teste tu tous les cas où tu peux avoir des IOException dans
ton code sans mock ? tous les cas ou l'API est violé et un null est
passé comme argument ? Effectivement tu va bien tester ton appli avec
des tests d'intégration lourd, mais le test untaire n'est pas là pour
ça. C'est plutôt pour mettre au point le code et ratisser toutes le
parties difficile à reproduire et à tester.

Pour ce faire, je préfère une approche à la Byteman (JBoss) qui me parait plus simple à implémenter.

Jeff
 

--
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

[Julien Vermillard]

Imagine tu utilise une API crypto qui chie des "no such algorithm exception"
Tu écris le code pour gérer ce genre de cas. Comment va tu tester ce
cas en test d'intégration ? c'est vraiment faisable de débrancher
l'algo que tu utilise ?
En mockant le service de crypto utilisé tu écris un test qui couvre le
cas en peu de ligne de code.

Après ça ne sauvera pas les chatons et n'évitera pas d'écrire des
tests fonctionnels complets. C'est un bon outil, dire que ca sert à
rien c'est mal connaitre l'outil (je pensais ca a une époque :).

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

[Patrice Trognon]

Oui enfin bon, voir l'historique de la liste parce que la je fatigue, entre les TU et les agiles je commence à revivre un jour sans fin.

Patrice

[Patrice Trognon]

Tu l'auras compris Julien ma réponse blasée ne t'était pas destiné à toi en particulier :) mais plus d'ordre général.

Patrice

Le 18 juil. 2012 à 22:15, Julien Vermillard <jverm...@gmail.com> a écrit :

[Julien Ponge]

> Pour ce faire, je préfère une approche à la Byteman (JBoss) qui me parait plus simple à implémenter.

+1

[Emmanuel Lécharny]

Le 7/18/12 10:06 PM, Patrice Trognon a écrit :

> bof, deja largement débattu j'ai déjà expliqué comment je fonctionne, les TU je m'en passe depuis longtemps/toujours
> avec mon couple debugger + tests fonctionnels

Tu changes radicalement de vision quand tu bosses sur une API, dont tu
n'imagines même pas ce que les utilisateurs vont en faire...

Si ton appli est à usage unique, c'est sûr, tout mocker, c'est se moquer
du monde.


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

[David Screve]

Ah ben justement, je reprends mon exemple SCEP....un serveur SCEP
génère des certificats d'après une CSR...si tu mock, tu vas juste
valider les appels à l'api, mais comme ton mock ne va générer que de
la m...., ben en fait tu ne vas rien tester....

Bon, mais ne me faites pas dire que je dis qu'il ne faut pas s'en
servir, hein !

Juste que pour moi, on peu bien mocker une base de données, pour le
reste je ne vois pas trop d'exemples......et du coup, les tests
d'integration et fonctionnels me semblent toujours plus riches.

David

On 18 juil, 22:15, Julien Vermillard <jvermill...@gmail.com> wrote:
> Imagine tu utilise une API crypto qui chie des "no such algorithm exception"
> Tu écris le code pour gérer ce genre de cas. Comment va tu tester ce
> cas en test d'intégration ? c'est vraiment faisable de débrancher
> l'algo que tu utilise ?
> En mockant le service de crypto utilisé tu écris un test qui couvre le
> cas en peu de ligne de code.
>
> Après ça ne sauvera pas les chatons et n'évitera pas d'écrire des
> tests fonctionnels complets. C'est un bon outil, dire que ca sert à
> rien c'est mal connaitre l'outil (je pensais ca a une époque :).
>

> 2012/7/18 Patrice Trognon <ptrog...@gmail.com>:

>
>
>
>
>
>
>
> > bof, deja largement débattu j'ai déjà expliqué comment je fonctionne, les TU je m'en passe depuis longtemps/toujours
> > avec mon couple debugger + tests fonctionnels
>
> > Pat
>
> > Le 18 juil. 2012 à 21:59, Julien Vermillard a écrit :
>
> >> Tu peux toujours t'en passer, tu va jute te priver d'un outil utile
> >> pour couvrir à fond certaine parties du code.
>

> >> 2012/7/18 Patrice Trognon <ptrog...@gmail.com>:

> >>> a quoi bon t'emmerder avec des tests unitaires si tes tests fonctionnels couvrent l'ensemble du domaine ?
>
> >>> ce que j'ai pu constater c'est que quand le client accepte de payer uniquement les tests unitaires il reste plein de merdes,
> >>> alors que quand le client nous a dit de ne pas faire de tests unitaires parce qu'il développait lui des tests fonctionnels on
> >>> n'avait quasiment aucun soucis en sorti de validation.
>
> >>> de la a en conclure que les tests unitaires ne servent a rien si on a une bonne couverture de tests fonctionnels on
> >>> peut le penser non ?
>
> >>> Pat
>
> >>> Le 18 juil. 2012 à 21:51, Julien Vermillard a écrit :
>
> >>>> Bill Burke, celui-là toujours à troller sans connaitre le fond du sujet :)
>
> >>>> Effectivement ne pas faire de test d'intégration (tester ton appli
> >>>> avec toutes la stack de démarrée) c'est une bétise. Par contre en
> >>>> déduire que les tests unitaires à base de mock sont une escroquerie,
> >>>> ca tiens du troll.
>
> >>>> Comment teste tu tous les cas où tu peux avoir des IOException dans
> >>>> ton code sans mock ? tous les cas ou l'API est violé et un null est
> >>>> passé comme argument ? Effectivement tu va bien tester ton appli avec
> >>>> des tests d'intégration lourd, mais le test untaire n'est pas là pour
> >>>> ça. C'est plutôt pour mettre au point le code et ratisser toutes le
> >>>> parties difficile à reproduire et à tester.
>
> >>>> Comme d'hab il mélange deux chose différente et les oppose pour créer un troll.
>
> >>>> Julien
>

> >>>> 2012/7/18 Emmanuel Bernard <emman...@lescastcodeurs.com>:

> >>>>> Je n'utilise pas d'outil de mock.
> >>>>> Un peu dans cette philosophie
> >>>>>http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/
>

> >>>>> 2012/7/18 Denis Sanchez <denis.sanc...@vif.fr>

>
> >>>>>> Bonjour à tous
> >>>>>> j'ai utilisé mockito et jmock comme framework de mock en environemment
> >>>>>> java. Et vous vous utilisez quoi?
> >>>>>> Quel est pour vous le plus simple d'utilisation et qui répond au mieux à
> >>>>>> vos besoins.
> >>>>>> Merci pour vos retours.
>
> >>>>>> Denis SANCHEZ
> >>>>>> Edition - Informatique opérationnelle
> >>>>>> VIF

> >>>>>> Tél.+33 (0)2 51 89 12 40
> >>>>>> Fax+33 (0)2 51 89 12 79
> >>>>>> denis.sanc...@vif.fr

[Patrice Trognon]

Le 18 juil. 2012 à 22:37, Emmanuel Lécharny a écrit :

> Le 7/18/12 10:06 PM, Patrice Trognon a écrit :
>> bof, deja largement débattu j'ai déjà expliqué comment je fonctionne, les TU je m'en passe depuis longtemps/toujours
>> avec mon couple debugger + tests fonctionnels
>
> Tu changes radicalement de vision quand tu bosses sur une API, dont tu n'imagines même pas ce que les utilisateurs vont en faire...
>

ok je veux bien te croire et en effet je l'imagine aisément.
ce sont des applies que je développe, principalement dans le domaine de l'UI parfois des démons.

Pat

> Si ton appli est à usage unique, c'est sûr, tout mocker, c'est se moquer du monde.
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

[Emmanuel Bernard]

Comment teste tu tous les cas où tu peux avoir des IOException dans
ton code sans mock ? tous les cas ou l'API est violé et un null est
passé comme argument ? Effectivement tu va bien tester ton appli avec
des tests d'intégration lourd, mais le test untaire n'est pas là pour
ça. C'est plutôt pour mettre au point le code et ratisser toutes le
parties difficile à reproduire et à tester.

Pour ce faire, je préfère une approche à la Byteman (JBoss) qui me parait plus simple à implémenter.

Absolument, et tu couvres aussi les cas d'accès concurrents qui ne sont pas nécessairement couvert par les mocks.

[Julien Ponge]

Oui avec Byteman tu rends déterministe la concurrence en agissant sur les threads (pause, explosion, syncho, ...), tu peux simuler des erreurs d'IO, ou plus généralement changer arbitrairement les retours des méthodes de tes APIs. Bien plus facile à mettre en œuvre (moins intrusif) que de passer par du mock dans ces cas la. 

--

[Emmanuel Lécharny]

Le 7/19/12 10:04 AM, Julien Ponge a écrit :

> Oui avec Byteman tu rends déterministe la concurrence en agissant sur les
> threads (pause, explosion, syncho, ...), tu peux simuler des erreurs d'IO,
> ou plus généralement changer arbitrairement les retours des méthodes de tes
> APIs. Bien plus facile à mettre en œuvre (moins intrusif) que de passer par
> du mock dans ces cas la.

Dès que tu voudras simuler des objets complexes, tu vas arriver à la
limite. Le mock a l'avantage de simuler ton API sans nécessairement
avoir tout à réimplémenter. Dans quelques cas, c'est utile.

Un mock n'a par contre pas la prétention de simuler les cas que tu cites.

Je suis un peu de l'avis d'Emmanuel (B), dans la vaste majorité des cas,
je ne vois pas pourquoi me faire chier avec les mocks. Cela dit, il ne
faut pas être dogmatique, et sur mon projet, on en utilise, mais sans
framework (on se contente d'implémenter les APIs qu'on a définit, avec
les comportements nécessaires pour le test). Au final, tout mocker,
c'est juste overkilling... Ne rien mocker, c'est nier le fait que
parfois, il faut tester au fond des choses à partir du haut.

J'aime bien les idées que Byteman pousse par contre : la possibilité de
simuler de la concurrence, c'est bien utile parfois. Faudra que je
pousse les feux de ce côté là pour la prochaine itération :) Si c'est
pas agile, ça...

[Moandji Ezana]

Je pense que les mocks ont été sur-utilisés à un moment parce que faire des tests d'intégration avec un container, c'était beaucoup trop long. Aujourd'hui il y a Arquillian et même JBoss démarre en un clin d'oeil, alors la donne est différente.

J'aime beaucoup Mockito, mais j'essaie d'utiliser le minimum de mocks/stubs/fakes et le minimum de features. Si une classe ou méthode a besoin de plus de 2-3 mocks, ainsi que de mocking complexe, il y a probablement un problème d'API. C'est ce que disent Freeman et Pryce dans Growing Object-Oriented Software: "Listen to your tests". D'ailleurs, ils recommandent de faire des "end-to-end tests" le plus tôt possible, sans pour autant nier l'utilité des tests unitaires. Beaucoup d'opérations style CRUD et logique métier légère bénéficient plus de tests d'intégration.

Est-ce que quelqu'un a déjà réalisé une séparation complète des tests UI et tests back-end? C'est-à-dire avoir une API bien définie entre les deux, qui est utilisée pour les tests d'intégration back-end et ré-implémentée sous forme de stub pour les tests UI. Je ne l'ai jamais fait, mais avec la prolifération de clients lourds (browser ou natifs), ça pourrait être utile?

Moandji

[ehsavoie]

Vous avez des pointeurs pour des tests JUnit avec Byteman ?

[Patrice Trognon]

je vais répondre par le petit bout de ma lorgnette, a savoir de l'applie ios native avec un serveur.

Le serveur expose un certain nombre de services, chaque service va répondre a une question, il a donc
des paramètres en entrée, et il renvoie une et une seule réponse ou erreur. le code est très défensif c'est
à dire que tous les cas d'erreur sont traités. Ca c'est assez facile à tester unitairement, et pas forcement besoin
de framework pour cela.

Ensuite branchement de l'UI, la pas de bouchon, l'UI fonctionne avec le serveur ou ne fonctionne pas (bien
sur le cas du serveur injoignable doit être géré mais bon c'est une évidence puisque si ce n'est pas
fait apple va retocker lors de la validation).

En développement je vais bouchonner mon UI si les services serveurs ne sont pas terminé, cela me permet
d'avancer sur le code propre a cette partie, une fois que les services serveur sont disponible je vais
les brancher et c'est la que les tests vont commencer, on est dans de l'UI donc celui qui test est un humain.
Souvent je vais faire le test de l'idiot, c'est a dire que je vais placer l'applie dans les mains d'un utilisateur,
ne strictement rien lui dire et je lui demande de tester, j'observe ses réactions et je repars corriger en fonction.

par exemple j'ai développé un jeu pour des enfants sur iPad, la cible étant à partir de 2 ans 1/2 en gros, sans ce
genre de test a observer l'enfant je n'aurai jamais abouti, et encore parfois j'ai mis longtemps a comprendre ce qui
clochait dans mon interface et qui faisait que l'enfant ne comprenait pas le but du jeu. mais je dérive :)

Mais dans tous les cas tu vois que le mock connait pas :)

Pat

> Moandji

[Julien Ponge]

> Vous avez des pointeurs pour des tests JUnit avec Byteman ?

https://speakerdeck.com/u/jponge/p/manipulation-de-bytecode-au-marsjug-juin-2012

[Moandji Ezana]

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

Souvent je vais faire le test de l'idiot, c'est a dire que je vais placer l'applie dans les mains d'un utilisateur,
ne strictement rien lui dire et je lui demande de tester, j'observe ses réactions et je repars corriger en fonction.

J'ai l'impression que le test utilisateur, ça répond à d'autres questions: "Est-ce que le produit est adapté/utile/utilisable/agréable?" Les tests automatisés répondent à d'autres questions.

Moandji

[Emmanuel Bernard]

2012/7/19 Moandji Ezana <mwa...@gmail.com>

J'ai l'impression que le test utilisateur, ça répond à d'autres questions: "Est-ce que le produit est adapté/utile/utilisable/agréable?" Les tests automatisés répondent à d'autres questions.

De toutes façon, tout bon informaticien sait que les utilisateurs c'est au mieux inutile au pire handicapant ;op

[Nicolas Capponi]

Citer Freeman et Pryce pour soutenir l'id�e que les mocks sont sur-utilis�s, c'est un peu fort quand m�me !
Leur approche consiste � mocker syst�matiquement tous les collaborateurs d'un objet.

Cela ne les emp�che effectivement pas d'�crire des tests end-to-end et des test d'int�gration avec les librairies externes.

S'il existe plusieurs types de tests, c'est parce qu'on ne peut pas r�pondre � tous les besoins avec un seul type.
La vitesse d'ex�cution n'est pas le seul crit�re, et d'ailleurs m�me dans ce cas il y a toujours une diff�rence
d'�chelle entre temps d'ex�cution de tests unitaires et temps d'ex�cution de tests d'int�gration avec Arquillian
(milliseconds vs secondes), qui peut devenir g�nante avec un nombre important de tests.

Nicolas Capponi

On 07/19/2012 11:07 AM, Moandji Ezana wrote:
> Je pense que les mocks ont �t� sur-utilis�s � un moment parce que faire des tests d'int�gration avec un container,
> c'�tait beaucoup trop long. Aujourd'hui il y a Arquillian et m�me JBoss d�marre en un clin d'oeil, alors la donne est
> diff�rente.

>
> J'aime beaucoup Mockito, mais j'essaie d'utiliser le minimum de mocks/stubs/fakes et le minimum de features. Si une

> classe ou m�thode a besoin de plus de 2-3 mocks, ainsi que de mocking complexe, il y a probablement un probl�me d'API.

> C'est ce que disent Freeman et Pryce dans Growing Object-Oriented Software: "Listen to your tests". D'ailleurs, ils

> recommandent de faire des "end-to-end tests" le plus t�t possible, sans pour autant nier l'utilit� des tests
> unitaires. Beaucoup d'op�rations style CRUD et logique m�tier l�g�re b�n�ficient plus de tests d'int�gration.
>
> Est-ce que quelqu'un a d�j� r�alis� une s�paration compl�te des tests UI et tests back-end? C'est-�-dire avoir une API
> bien d�finie entre les deux, qui est utilis�e pour les tests d'int�gration back-end et r�-impl�ment�e sous forme de
> stub pour les tests UI. Je ne l'ai jamais fait, mais avec la prolif�ration de clients lourds (browser ou natifs), �a
> pourrait �tre utile?
>
> Moandji
> --
> 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.

[Jeff MAURY]

Il y a la présentation de Julien PONGE à Devoxx France, sinon la doc est amplement suffisante pour démarrer (ça a du me prendre 10 mn pour tester un cas d'erreur java.io)

Jeff

2012/7/19 ehsavoie <emmanuel...@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

[Frédéric Bouquet]

De toutes façon, tout bon informaticien sait que les utilisateurs c'est au mieux inutile au pire handicapant ;op

Dis, dans ton cas, tes utilisateurs, c'est pas des informaticiens justement ? tu nous fait passer pour quoi dis donc ? :p

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

[Patrice Trognon]

va automatiser du test sur de l'UI, idem on en a déjà largement débattu ici, je pense que les différences d'approche ont été exprimés.

[Patrice Trognon]

certains valent le coup, voir un gamin rire aux éclats en jouant avec ce que tu as développé ça vaut tous les connards

qui t'on pris la tronche parce que la couleur du bouton n'est pas celle qu'ils voulaient :)

Pat

[Denis Sanchez]

Merci pour vos retours, mais je pense qu'on a un peu dévier du sujet.

Car la question était plutôt qu'est ce que vous utilisez comme framework pour mocker?

;-)

Denis SANCHEZ
Edition - Informatique opérationnelle
VIF
Tél. +33 (0)2 51 89 12 40
Fax +33 (0)2 51 89 12 79
denis....@vif.fr
www.vif.fr

[Laurent Forêt]

Très belle présentation. Ça m'a donné envie de mettre ça dans ma toolbox.

Merci.

Laurent Forêt
http://www.devcoop.fr

2012/7/19 Julien Ponge <julien...@gmail.com>

> Vous avez des pointeurs pour des tests JUnit avec Byteman ?

https://speakerdeck.com/u/jponge/p/manipulation-de-bytecode-au-marsjug-juin-2012

[Rémi Forax]

On 07/19/2012 04:43 PM, Laurent For�t wrote:
> Tr�s belle pr�sentation. �a m'a donn� envie de mettre �a dans ma toolbox.

sinon, il y a la pres d'Andrew Dynn (l'auteur qui bosse chez RedHat) au
dernier FOSDEM.
http://vimeo.com/36395894

Le truc vraiement cool, et c'est dommage, ya pas eu de video est que
Karl Hegason (Mr Gervill)
a trouv� Byteman tellement chouette que le lendemain de la pres sur
Byteman au lieu de faire sa pres sur Gervill,
il a pris un quart d'heure � montrer que en connectant ByteMan �
Gervill, il pouvait jouer des sons
� chaque fois qu'il y avait des allocations dans un code et que cela
permettait de debugger � l'oreille.
J'�tais dans la salle, je crois que j'ai jamais vu (entendu en
l'occurence) une pr�sentation aussi sympa.

>
> Merci.
>
> Laurent For�t
> http://www.devcoop.fr

R�mi

>
>
> 2012/7/19 Julien Ponge <julien...@gmail.com
> <mailto:julien...@gmail.com>>

>
> > Vous avez des pointeurs pour des tests JUnit avec Byteman ?
>
> https://speakerdeck.com/u/jponge/p/manipulation-de-bytecode-au-marsjug-juin-2012
>
> --

> 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.

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

[Moandji Ezana]

2012/7/19 Nicolas Capponi <capponi...@gmail.com>

Citer Freeman et Pryce pour soutenir l'idée que les mocks sont sur-utilisés, c'est un peu fort quand même !
Leur approche consiste à mocker systématiquement tous les collaborateurs d'un objet.

Peut-être, mais un test où il faut mocker 15 collaborateurs, ça fait mal, donc il faut peut-être repenser le design.

S'il existe plusieurs types de tests, c'est parce qu'on ne peut pas répondre à tous les besoins avec un seul type.

Tout à fait d'accord.  

Moandji

[Nicolas Capponi]

On 07/20/2012 07:51 AM, Moandji Ezana wrote:

2012/7/19 Nicolas Capponi <capponi...@gmail.com>

Citer Freeman et Pryce pour soutenir l'idée que les mocks sont sur-utilisés, c'est un peu fort quand même !
Leur approche consiste à mocker systématiquement tous les collaborateurs d'un objet.

Peut-être, mais un test où il faut mocker 15 collaborateurs, ça fait mal, donc il faut peut-être repenser le design.

Oui, c'est aussi un point essentiel de leur approche, si tu dois mocker beaucoup d'objets pour effectuer un test c'est que ton code est a priori mal conçu.

Comme la discussion était partie sur le fait que les mocks sont plutôt à éviter, je soulignais juste que Freeman et Pryce ont une approche exactement contraire, qui consiste à mocker systématiquement. Cela va de pair avec une approche où tu écris d'abord les tests (TDD - je ne le dis pas trop fort c'est mal vu par ici :-) ), ce qui permet de voir rapidement si ton design doit être repensé (plutôt que de coder, t'apercevoir que c'est trop complexe à mocker et tout recoder).


Sinon, pour répondre à la question initiale, j'utilise Mockito que je trouve plus simple à utiliser et lisible qu'EasyMock et jmock.
Comme déjà dit dans un message du thread, le fait que Mockito retourne des valeurs par défaut peut poser problème. Cependant depuis la version 1.7, il est possible de changer le retour par défaut, plusieurs stratégies sont implémentées.

Nicolas Capponi

S'il existe plusieurs types de tests, c'est parce qu'on ne peut pas répondre à tous les besoins avec un seul type.

Tout à fait d'accord.  

Moandji

--

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.

[Emmanuel Lécharny]

Le 7/20/12 10:53 AM, Nicolas Capponi a écrit :

> On 07/20/2012 07:51 AM, Moandji Ezana wrote:
>> 2012/7/19 Nicolas Capponi <capponi...@gmail.com

>> <mailto:capponi...@gmail.com>>

>>
>> Citer Freeman et Pryce pour soutenir l'idée que les mocks sont
>> sur-utilisés, c'est un peu fort quand même !
>> Leur approche consiste à mocker systématiquement tous les
>> collaborateurs d'un objet.
>>
>>
>> Peut-être, mais un test où il faut mocker 15 collaborateurs, ça fait
>> mal, donc il faut peut-être repenser le design.
>
> Oui, c'est aussi un point essentiel de leur approche, si tu dois
> mocker beaucoup d'objets pour effectuer un test c'est que ton code est
> a priori mal conçu.
>
> Comme la discussion était partie sur le fait que les mocks sont plutôt
> à éviter, je soulignais juste que Freeman et Pryce ont une approche
> exactement contraire, qui consiste à mocker systématiquement. Cela va
> de pair avec une approche où tu écris d'abord les tests (TDD - je ne
> le dis pas trop fort c'est mal vu par ici :-) ), ce qui permet de voir
> rapidement si ton design doit être repensé (plutôt que de coder,
> t'apercevoir que c'est trop complexe à mocker et tout recoder).

Et quand t'as tout mocké, tout TDDisé, il te reste du temps pour *CODER* ???

Sérieux, ça s'arrêtera un jour ces conneries de logique positivistes,
qui consiste à dire que pour vérifier l'infini, il faut compter jusqu'au
bout, sinon, c'est pas sûr que l'infini est infini ?

/me constate qu'on est déjà vendredi...

[Nicolas Capponi]

On 07/20/2012 11:15 AM, Emmanuel L�charny wrote:
> Le 7/20/12 10:53 AM, Nicolas Capponi a �crit :

>> On 07/20/2012 07:51 AM, Moandji Ezana wrote:
>>> 2012/7/19 Nicolas Capponi <capponi...@gmail.com <mailto:capponi...@gmail.com>>
>>>

>>> Citer Freeman et Pryce pour soutenir l'id�e que les mocks sont sur-utilis�s, c'est un peu fort quand m�me !

>>> Leur approche consiste � mocker syst�matiquement tous les collaborateurs d'un objet.
>>>
>>>
>>> Peut-�tre, mais un test o� il faut mocker 15 collaborateurs, �a fait mal, donc il faut peut-�tre repenser le design.

>>
>> Oui, c'est aussi un point essentiel de leur approche, si tu dois mocker beaucoup d'objets pour effectuer un test

>> c'est que ton code est a priori mal con�u.
>>
>> Comme la discussion �tait partie sur le fait que les mocks sont plut�t � �viter, je soulignais juste que Freeman et
>> Pryce ont une approche exactement contraire, qui consiste � mocker syst�matiquement. Cela va de pair avec une
>> approche o� tu �cris d'abord les tests (TDD - je ne le dis pas trop fort c'est mal vu par ici :-) ), ce qui permet de
>> voir rapidement si ton design doit �tre repens� (plut�t que de coder, t'apercevoir que c'est trop complexe � mocker
>> et tout recoder).
>
> Et quand t'as tout mock�, tout TDDis�, il te reste du temps pour *CODER* ???

Il faut arr�ter de jouer sur les mots, faire du TDD, c'est coder, et tu peux le faire avec ou sans mock d'ailleurs. Je
ne vois pas bien o� est le probl�me.
Si quelqu'un fait des tests, tu lui demandes pourquoi il ne CODE plus au lieu d'�crire tous ces tests ?
J'ai pratiqu� les trois approches (sans test, test avant, test apr�s), et je n'ai pas l'impression de perdre en
productivit� si je fais du TDD.

>
> S�rieux, �a s'arr�tera un jour ces conneries de logique positivistes, qui consiste � dire que pour v�rifier l'infini,
> il faut compter jusqu'au bout, sinon, c'est pas s�r que l'infini est infini ?
Je ne vois pas le rapport avec le sujet. L'objectif est d'avoir du feedback sur ton code, pas de tout v�rifier. Mais
on peut philosopher j'aime bien �a !
>
> /me constate qu'on est d�j� vendredi...
>

[Manu]

Non mais les tests c'est pour les mauvais ou les mecs pas sur d'eux ...

... ou encore pour ceux qui n'ont pas de canard en plastique :

http://fr.wikipedia.org/wiki/M%C3%A9thode_du_canard_en_plastique 

2012/7/20 Nicolas Capponi <capponi...@gmail.com>

On 07/20/2012 11:15 AM, Emmanuel Lécharny wrote:

Le 7/20/12 10:53 AM, Nicolas Capponi a écrit :

On 07/20/2012 07:51 AM, Moandji Ezana wrote:

2012/7/19 Nicolas Capponi <capponi...@gmail.com <mailto:capponi.nicolas@gmail.com>>

    Citer Freeman et Pryce pour soutenir l'idée que les mocks sont sur-utilisés, c'est un peu fort quand même !

    Leur approche consiste à mocker systématiquement tous les collaborateurs d'un objet.


Peut-être, mais un test où il faut mocker 15 collaborateurs, ça fait mal, donc il faut peut-être repenser le design.

Oui, c'est aussi un point essentiel de leur approche, si tu dois mocker beaucoup d'objets pour effectuer un test c'est que ton code est a priori mal conçu.

Comme la discussion était partie sur le fait que les mocks sont plutôt à éviter, je soulignais juste que Freeman et Pryce ont une approche exactement contraire, qui consiste à mocker systématiquement. Cela va de pair avec une approche où tu écris d'abord les tests (TDD - je ne le dis pas trop fort c'est mal vu par ici :-) ), ce qui permet de voir rapidement si ton design doit être repensé (plutôt que de coder, t'apercevoir que c'est trop complexe à mocker et tout recoder).

Et quand t'as tout mocké, tout TDDisé, il te reste du temps pour *CODER* ???

Il faut arrêter de jouer sur les mots, faire du TDD, c'est coder, et tu peux le faire avec ou sans mock d'ailleurs. Je ne vois pas bien où est le problème.
Si quelqu'un fait des tests, tu lui demandes pourquoi il ne CODE plus au lieu d'écrire tous ces tests ?
J'ai pratiqué les trois approches (sans test, test avant, test après), et je n'ai pas l'impression de perdre en productivité si je fais du TDD.

Sérieux, ça s'arrêtera un jour ces conneries de logique positivistes, qui consiste à dire que pour vérifier l'infini, il faut compter jusqu'au bout, sinon, c'est pas sûr que l'infini est infini ?

  Je ne vois pas le rapport avec le sujet. L'objectif est d'avoir du feedback sur ton code, pas de tout vérifier. Mais on peut philosopher j'aime bien ça !

/me constate qu'on est déjà vendredi...

--

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.

[Manu]

Et sinon j'utilise plutôt Mockito :)

2012/7/20 Manu <mek...@gmail.com>

[David Screve]

<vendredi>
Moi, quand je reçois des amis, je commence par mettre la table....la,
vient alors spontanément la question de ce que je vais leur faire à
manger.....du coup, je commence à cuisiner, puis au fur et à mesure
que je lis la recette choisie, je fais les courses à chaque fois qu'il
me manque un ingrédient...... Des fois faut aussi changer la recette
en cours de route et tout recommencer si un végétarien arrive à
l'improviste ..pratique pour bouffer du mcdo, pas idéal pour un
bourguignon.....l'avantage, c'est que je n'ai pas acheté trop à
bouffer puisque s'il y a un invité de plus, je vais tout de suite
acheter le complément.....
</vendredi>

On 20 juil, 17:28, Nicolas Capponi <capponi.nico...@gmail.com> wrote:
> On 07/20/2012 11:15 AM, Emmanuel L charny wrote:
>
>
>
>
>
>
>
>
>
> > Le 7/20/12 10:53 AM, Nicolas Capponi a crit :
> >> On 07/20/2012 07:51 AM, Moandji Ezana wrote:

> >>> 2012/7/19 Nicolas Capponi <capponi.nico...@gmail.com <mailto:capponi.nico...@gmail.com>>

[Manu]

<reply-to-vendredi>

Chaque début d'année, je prévois l'ensemble des repas que je vais faire dans l'année.

C'est un peu compliqué par qu'il faut que j'anticipe tous les repas d'amis, de famille, avec mes collègues

que je vais organiser chez moi mais aussi tous les repas ou je serais inviter dans l'année et ne serais

donc pas chez moi pour y manger.

Il faut aussi aussi que je réfléchisses à mes vacances, à mes week ends et que j'anticipe tous les imprévus

qui vont m'obliger à manquer un repas.

Pour les menus, j'essaie de prévoir aussi à l'avance ce que je vais avoir envie de manger dans l'année.

Une fois tout ça définit, je ne change plus d'envie et je me tiens à mon planning.

Je ne choisis plus mes repas en fonction de mes envies et dès fois quand mes amis sortent, je n'y vais pas

car j'avais prévu de manger à la maison et inversement, certains soirs, je ne mange pas car je pensais que mes amis

organiseraient une soirée...

</reply-to-vendredi>

Les métaphores sont faciles à retourner ;)

2012/7/21 David Screve <david....@gmail.com>

[Patrice Trognon]

Je ne comprend pas vos métaphores un codeur ca bouffe des chips avec du coca, et pour équilibrer de temps en temps du riz sauce tomate ou des nouilles.

Patrice

[David Screve]

J'adore les vendredi...merci Patrice et Manu ;))))

On 21 juil, 08:41, Patrice Trognon <ptrog...@gmail.com> wrote:
> Je ne comprend pas vos métaphores un codeur ca bouffe des chips avec du coca, et pour équilibrer de temps en temps du riz sauce tomate ou des nouilles.
>
> Patrice
>

> Le 21 juil. 2012 à 08:39, Manu <mekt...@gmail.com> a écrit :
>
>
>
>
>
>
>
> > <reply-to-vendredi>
> > Chaque début d'année, je prévois l'ensemble des repas que je vais faire dans l'année.
> > C'est un peu compliqué par qu'il faut que j'anticipe tous les repas d'amis, de famille, avec mes collègues
> > que je vais organiser chez moi mais aussi tous les repas ou je serais inviter dans l'année et ne serais
> > donc pas chez moi pour y manger.
> > Il faut aussi aussi que je réfléchisses à mes vacances, à mes week ends et que j'anticipe tous les imprévus
> > qui vont m'obliger à manquer un repas.
> > Pour les menus, j'essaie de prévoir aussi à l'avance ce que je vais avoir envie de manger dans l'année.
> > Une fois tout ça définit, je ne change plus d'envie et je me tiens à mon planning.
> > Je ne choisis plus mes repas en fonction de mes envies et dès fois quand mes amis sortent, je n'y vais pas
> > car j'avais prévu de manger à la maison et inversement, certains soirs, je ne mange pas car je pensais que mes amis
> > organiseraient une soirée...
> > </reply-to-vendredi>
>
> > Les métaphores sont faciles à retourner ;)
>

> > 2012/7/21 David Screve <david.scr...@gmail.com>

[Emmanuel Lécharny]

Le 7/20/12 5:28 PM, Nicolas Capponi a écrit :
> On 07/20/2012 11:15 AM, Emmanuel Lécharny wrote:
>> Le 7/20/12 10:53 AM, Nicolas Capponi a écrit :

>>> On 07/20/2012 07:51 AM, Moandji Ezana wrote:
>>>> 2012/7/19 Nicolas Capponi <capponi...@gmail.com
>>>> <mailto:capponi...@gmail.com>>
>>>>

>>>> Citer Freeman et Pryce pour soutenir l'idée que les mocks sont
>>>> sur-utilisés, c'est un peu fort quand même !

>>>> Leur approche consiste à mocker systématiquement tous les
>>>> collaborateurs d'un objet.
>>>>
>>>>
>>>> Peut-être, mais un test où il faut mocker 15 collaborateurs, ça
>>>> fait mal, donc il faut peut-être repenser le design.

>>>
>>> Oui, c'est aussi un point essentiel de leur approche, si tu dois
>>> mocker beaucoup d'objets pour effectuer un test c'est que ton code

>>> est a priori mal conçu.
>>>

>>> Comme la discussion était partie sur le fait que les mocks sont
>>> plutôt à éviter, je soulignais juste que Freeman et Pryce ont une
>>> approche exactement contraire, qui consiste à mocker
>>> systématiquement. Cela va de pair avec une approche où tu écris

>>> d'abord les tests (TDD - je ne le dis pas trop fort c'est mal vu par

>>> ici :-) ), ce qui permet de voir rapidement si ton design doit être
>>> repensé (plutôt que de coder, t'apercevoir que c'est trop complexe à
>>> mocker et tout recoder).
>>
>> Et quand t'as tout mocké, tout TDDisé, il te reste du temps pour
>> *CODER* ???
>
> Il faut arrêter de jouer sur les mots, faire du TDD, c'est coder, et
> tu peux le faire avec ou sans mock d'ailleurs. Je ne vois pas bien où
> est le problème.

> Si quelqu'un fait des tests, tu lui demandes pourquoi il ne CODE plus

> au lieu d'écrire tous ces tests ?
> J'ai pratiqué les trois approches (sans test, test avant, test après),
> et je n'ai pas l'impression de perdre en productivité si je fais du TDD.
Bon, je vais être plus clair :

j'en ai plus que marre d'entendre des théoriciens de l'informatique qui
nous expliquent à longueur de blog/tweet/O1-informatique que la secret
de la réussite d'un projet informatique, c'est d'écrire les tests
d'abord, et que le projet va magiquement se construire tout seul.

C'est du PIPEAU.

C'est équivalent à penser qu'un constructeur automobile va d'abord
imaginer ses crash tests, et construire sa voiture en fonction des crash
tests.

Les tests sont indispensables, mais ne sont que les outils qui
permettent de vérifier que le code du projet répond aux besoins.

Et non, tester, ce n'est pas coder. Tester, c'est tester. Je ne livre
pas des tests à mettre en production, je livre une application, avec les
tests qui vont avec.

Mort à TDD ! Vive les tests !

PS : La plupart du temps, quand je rentre sur un projet qui doit
évoluer, les problèmes que je rencontre suite à une évolution ne sont
pas liés à la qualité du code du projet, ni de l'impact des
modifications sur le code du projet, mais sur les tests qui ne passent
pas parce que les tests sont FOIREUX. Oui, foireux. Et je suis bien
placé pour en parler, sur mes projets favoris où j'ai plusieurs milliers
de tests, à chaque modif fonctionnelle ou technique, et à chaque fois je
constate que certains tests sont simplement invalides. Il faut faire
quoi alors ? Tester les tests ? Du TDD de TDD ? Et du TDD de TDD de TDD ?

A un moment, il faut arrêter, reconsidérer ce qu'est le métier
d'informaticien, poser ses livres de méthodologies et autres
bullshitters qui t'expliquent ce qu'il faut faire mais qu'ils ne font
jamais, eux, parce qu'ils passent leurs journées à faire des cours
grassement payés, pour revenir à la base...

[Patrice Trognon]

On le sait tout ça Emmanuel, mais si tu enlèves tous les trucs fumeux (TDD, agilité, ....) de quoi vivront les consultants.

Je plussoie totalement ton analyse et même énervement !


Patrice

[Altus34]

 j'en ai plus que marre d'entendre des théoriciens de l'informatique qui nous expliquent à longueur de blog/tweet/O1-informatique que la secret de la réussite d'un projet informatique, c'est d'écrire les tests d'abord, et que le projet va magiquement se construire tout seul.

=> On est tous d'accord avec ca. La qualité des hommes sur un projet est l'élément numéro 1 ;)

C'est équivalent à penser qu'un constructeur automobile va d'abord imaginer ses crash tests, et construire sa voiture en fonction des crash tests.

=> Mauvaise annalogie un crash test n'est pas un test unitaire ;) ca serait plus un test de résistance ou de montée en charge ;)

Justement les gars dans l'industrie il ne font QUE ca tester avant de produire. Ils simulent avec leurs outils informatique 100 fois la pièce

Ils testent sont aérodynamisme, résistance .... en simluation virtuel puis seulement apres fabrique la pièce (et encore parfois même pas dans le materiaux final)

Bref ils unit test pièce par pièce,  composant par composant, module par module pour au final assembler un  vrai premier prototype.

Ne pas faire de test unitaire c'est comme designer une voiture ou il faut refabriquer le moteur à chaque fois q'un petit élément à changé.

Pour moi le gros problème du TDD et c'est ce qui emmerde TOUT le monde c'est qu'il révèle que notre industrie est une industrie disfonctionel ou max.

On pense encore que les dev sont les gars sur la chaine de montage alors qu'elle n'existe pas en informatique cette chaine de montage.

Aujourd'hui quand je fait du TDD je réalise plusieurs activitée : design, coding, testing, documentation, infra.

Ma productivité en tant que dev est elle diminuée ? Non je ne le pense pas. Je fait beaucoup plus de truc qu'avant en moins de temps sauf que je fait BEAUCOUP plus de truc qu'avant => BEAUCOUP plus de truc qu'avant (ca y est manager c'est rentré dans ta tête .. 3 fois normalement c'est suffisant ou un cerveau moyen  ;))

Donc je pense que le manager qui va venir me retirer la seule pratique d'ingénieurie qui me permet de conserver un controle sur mon code je lui dit ciao ... amuse toi bien avec ton projet moi je vais jouer ailleur ;)

2012/7/21 Patrice Trognon <ptro...@gmail.com>

[Emmanuel Lécharny]

Le 7/21/12 5:44 PM, Altus34 a écrit :

> j'en ai plus que marre d'entendre des théoriciens de l'informatique qui
> nous expliquent à longueur de blog/tweet/O1-informatique que la secret de
> la réussite d'un projet informatique, c'est d'écrire les tests d'abord, et
> que le projet va magiquement se construire tout seul.
>
> => On est tous d'accord avec ca. La qualité des hommes sur un projet est
> l'élément numéro 1 ;)
>
> C'est équivalent à penser qu'un constructeur automobile va d'abord imaginer
> ses crash tests, et construire sa voiture en fonction des crash tests.
>
> => Mauvaise annalogie un crash test n'est pas un test unitaire ;) ca serait
> plus un test de résistance ou de montée en charge ;)

Je parle de crash tests, mais hier, j'ai discuté avec un collègue dont
le cousin bosse sur des calculateurs embarqués. Ils font 7 heures de
tests sur ces éléments une fois ceux-ci produit. 9a parait effectivement
assez sain pour des éléments qui se trouvent dans un avion...

Malgré tout, ces tests sont constitués en partie à partir des
spécifications, et en partie suite aux erreurs détectées. Finalement, un
peu comme ce que l'on fait : on a des specs, donc on sait ce que l'on
doit tester, et quand on détecte un bug, on rajoute un test.

De surcroit, il s'agit de tests en boîte noire, pas de tests en boîte
blanche. Nous, ce sont les tests en boîtes blanches qui nous intéressent
au premier chef, et désolé, mais sauf cas d'espèce (ie API), essayer
d'imaginer tous les tests avant de développer c'est essayer mettre la
charrue avant les boeufs.

>
> Justement les gars dans l'industrie il ne font QUE ca tester avant de
> produire. Ils simulent avec leurs outils informatique 100 fois la pièce
> Ils testent sont aérodynamisme, résistance .... en simluation virtuel puis
> seulement apres fabrique la pièce (et encore parfois même pas dans le
> materiaux final)
> Bref ils unit test pièce par pièce, composant par composant, module par
> module pour au final assembler un vrai premier prototype.

Il y a un petit point que tu omets de dire, et qui fait toute la
différence : dans l'industrie, ils produisent à plus d'une unité. Par
ailleurs, leurs outils de modélisations s'appliquent sur des éléments
tangibles, pas nous.

>
> Ne pas faire de test unitaire c'est comme designer une voiture ou il faut
> refabriquer le moteur à chaque fois q'un petit élément à changé.

je n'ai jamais dit qu'il ne fallait pas faire de tests unitaire. Par
contre, je trouve l'approche TDD complètemet stupide, infantilisante et
contre-productive.

>
> Pour moi le gros problème du TDD et c'est ce qui emmerde TOUT le monde
> c'est qu'il révèle que notre industrie est une industrie disfonctionel ou
> max.

Non. Ce qui emmerde tut le monde avec TDD c'est que ça te fait croire
qu'en écrivant le stests d'abord, tu vas magiquement rendre notre métier
prédictif et industriel. C'est un leurre.

La seule et unique raison pour laquelle TDD a eu du succès, c'est parce
que cela force les développeurs à ECRIRE DES TESTS. Si on attend qu'ils
le fassent à la fin du projet, on est toujours à court de temps, du coup
on livre à l'arrache, en espérant que ça marchera. Avec TDD, tu es censé
inverser le process : tu commences par les tests, et avec un peu de
chance, tu auras le temps de coder ton appli dans le temps qu'il te
restera... Sur un projet un peu gros, je rigol d'avance ...

> On pense encore que les dev sont les gars sur la chaine de montage alors
> qu'elle n'existe pas en informatique cette chaine de montage.
>
> Aujourd'hui quand je fait du TDD je réalise plusieurs activitée : design,
> coding, testing, documentation, infra.

Tu designes des tests, pas une appli. Du coup, ton appli sera écrite en
focntion de tes tests, et non en fonction de ton besoin. C'ets juste
aberrant.

Désolé, je code ET j'écrit des tests unitaires, il m'arrive même de
définir mes tests unitaires avant de coder mon appi, mais uniquement
dans le cas d'une API qui sera exposé à un publique large, donc je me
couvre au maximum dans ce cas (et on s'approche d'une vision
industrielle). Mais dans ce cas précis, mon API est déjà parfaitement
décrite, et laisse peu de place à l'improvisation.

Dans tous les autres cas, commencer par les tests me créé un carcan
manetal et technique qui me limite dans l'écriture de mon appli.

Sans compter qu'il faudra m'expliquer comment tu peux écrire tout tes
tests sans code, sauf à mocker comme un fou tous les composants dont tu
ne sais pas d'avance comment ils vont s'architecturer dans l'avenir.

TDD, c'est une vue de l'esprit vendu par des consultants à des DI en mal
de sécurisation, et qui pensent que parce que les tests sont écrit
avant, alors les applis seront correctes. Bullshit.

Mais, bon, s'il y en a pour qui ça marche, pas de soucis. On se revoit
dans 10 ans !

[David Screve]

Bah...comme disait Patrice, tout dépend de ce qu'on code....nous, dans
ce qu'on développe, si on faisait du TDD, on multiplierai par 4 les
coûts de développement pour un gain proche de zéro, car on code très
défensif, avec 90% d'interaction avec des systèmes externes très
divers et donc, mocker, pour nous, ça veut dire réécrire le monde
entier.....

Pour des API, des applications de gestion server-centric, je veux
bien.....mais bon, un client SCEP, un moteur MDM, des applications
graphiques, un accéléromètre, le TDD est fort peu utile, et comme tu
le dis toi-même, le gros risque du TDD est d'influer sur
l'architecture de l'application et, par ricochet, d'influer sur l'IHM
et l'ergonomie de l'application. Et ça, c'est un très gros risque à
mes yeux. Or, pour moi l'Utilisateur est ma seule et unique
préoccupation, le reste n'est que cuisine et bricolage technique....

David

[Patrice Trognon]

Oui j'ai quelque peu évolué sur le sujet suite à nos discussions, en effet dans le domaine qui est le notre c'est inapplicable et la bonne vielle méthode de codage défensif + debug obligatoire + tests fonctionnels est parfaite.
Maintenant je veux bien admettre que dans le domaine jee et dans celui de l'écriture d'api (ou de frameworks pour être à la mode) cela soit important, maintenant à lire emmanuel (L et B) j'ai quand même du mal à dire indispensable, mais bon chacun son domaine et faites comme vous voulez j'en ferai de même de mon côté :)

Patrice

[Nicolas Delsaux]

2012/7/21 Emmanuel Lécharny <elec...@gmail.com>:

>
> j'en ai plus que marre d'entendre des théoriciens de l'informatique qui nous
> expliquent à longueur de blog/tweet/O1-informatique que la secret de la
> réussite d'un projet informatique, c'est d'écrire les tests d'abord, et que
> le projet va magiquement se construire tout seul.
>
> C'est du PIPEAU.

Pas vraiment faux, mais pas totallement vrai non plus : si tes tests
sont des "specs exécutables", alors tu les écris avant (typiquement
dans le cas d'une API c'est une façon pratique de décider comment
l'écrire).

En revanche, pour les cas limites, les bugs, les régressions, tout ça,
c'est juste idiot d'essayer de les écrire avant : ceux-là, tu les
écris quand tu fixe le bg et tu les appelle "Test_for_bug_1954"

>
> Les tests sont indispensables, mais ne sont que les outils qui permettent de
> vérifier que le code du projet répond aux besoins.

Tutafé

>
> Et non, tester, ce n'est pas coder. Tester, c'est tester. Je ne livre pas
> des tests à mettre en production, je livre une application, avec les tests
> qui vont avec.
>

> PS : La plupart du temps, quand je rentre sur un projet qui doit évoluer,
> les problèmes que je rencontre suite à une évolution ne sont pas liés à la
> qualité du code du projet, ni de l'impact des modifications sur le code du
> projet, mais sur les tests qui ne passent pas parce que les tests sont
> FOIREUX. Oui, foireux. Et je suis bien placé pour en parler, sur mes projets
> favoris où j'ai plusieurs milliers de tests, à chaque modif fonctionnelle ou
> technique, et à chaque fois je constate que certains tests sont simplement
> invalides. Il faut faire quoi alors ? Tester les tests ? Du TDD de TDD ? Et
> du TDD de TDD de TDD ?

Sur ce sujet-là, je me suis toujours demandé (sans jamais avoir
vraiment le temps d'y penser) si un truc comme NoUnit (ou l'autre, là,
qui change le code de ton application en remplacant les if(true) par
des if(false)) n'était pas une forme de solution : tu vérifie que le
test "bloque" bien la partie du code testé. Et quand je dis "bloque",
je ne dis que ça : si ton test vérifie un truc, c'est le
fonctionnement de ton application à un instant t. Tu changes un bout
de spec qui impacte le code testé ? Ben t'es bon pour refaire le test.
Et en ce sens, le code de test fait partie du code de l'application :
il doit vivre et être documenté. Et ça, c'est la vraie galère !

--
Nicolas Delsaux

[Nicolas Capponi]

> j'en ai plus que marre d'entendre des théoriciens de l'informatique qui nous
> expliquent à longueur de blog/tweet/O1-informatique que la secret de la
> réussite d'un projet informatique, c'est d'écrire les tests d'abord, et que
> le projet va magiquement se construire tout seul.

> Non. Ce qui emmerde tut le monde avec TDD c'est que ça te fait croire qu'en écrivant les tests d'abord, tu vas magiquement rendre notre métier prédictif et industriel. C'est un leurre.

Je pense qu'il faut séparer la critique du discours sur le TDD de la critique de la pratique elle-même.

Ceux qui présentent ou vendent le TDD comme le truc magique qui résoud tous les problèmes jouent effectivement du pipeau. Ce ne seront ni les premiers, ni les derniers à le faire, lorsqu'une techno ou une pratique devient un buzzword on y a systématiquement droit.

Si on oublie tous les magiciens et qu'on s'intéresse à la pratique, quelles sont les critiques ?

1) Faire du TDD, c'est passer son temps à écrire des tests

> Et non, tester, ce n'est pas coder. Tester, c'est tester. Je ne livre pas des tests à mettre en production, je livre une application, avec les tests qui vont avec.

> Avec TDD, tu es censé inverser le process : tu commences par les tests, et avec un peu de chance, tu auras le temps de coder ton appli dans le temps qu'il te restera... Sur un projet un peu gros, je rigol d'avance ...

    

 Lorsqu'on fait du TDD, on n'écrit pas tous les tests d'un coup puis ensuite le code de l'appli. On écrit un test, puis le code, puis un autre test, puis le code.

 Donc au bout d'une heure par exemple, tu n'as pas que des tests, tu a bien écrit du code pour ton appli, qui partira en production. Et tu as les tests qui vont avec.  

 Projet petit ou gros, tu ne repousse par l'écrire de ton appli à la fin.

2) L'approche TDD est stupide

 Argument gratuit, sans plus de précisions je ne vois pas ce qu'on pourrait répondre.

3) L'approche TDD est infantilisante

 C'est un reproche fait au discours autour du TDD (et que je trouve valide comme dit plus haut). En soi je ne vois pas en quoi la pratique elle-même est infantilisante.  

 

4) L'approche TDD est contre-productive

 L'expérience que j'en ai est positive de ce point de vue. J'ai constaté une amélioration (forcément subjective) de la qualité de code produit.

 Mais je me garderais bien de généraliser et de prétendre que c'est tout le temps le cas, en fonction des types d'applis et contextes, de l'équipe.

 Les quelques études scientifiques existantes sont apparemment contrastées (cf par exemple http://referentiel.institut-agile.fr/tdd.html, au bas de la page) 

 La conclusion, c'est qu'il aussi abusif d'affirmer aujourd'hui que c'est la "silver bullet" que d'affirmer que ça ne fonctionne jamais.

 

5) L'application sera écrite en fonction des tests plutôt que du besoin

> Tu designes des tests, pas une appli. Du coup, ton appli sera écrite en focntion de tes tests, et non en fonction de ton besoin. C'ets juste aberrant.

Uh ? Les tests sont juste une technique qui te permet d'écrire ton appli (ta classe en fait puisqu'on parle de test U) d'un point de vue externe plutôt qu'interne. Et le design des tests est suffisamment

contraint pour ne pas te dérouter du design de ton appli. Pour le coup, tu exprimes ton besoin - quel rôle joue l'objet, quelle interface il expose ? - avant de te lancer dans l'implémentation.

Cela nécessite un certain entraînement au début car on n'a pas l'habitude. Ce qui explique aussi qu'on perd en productivité lorsqu'on commence l'approche TDD, ceux qui disent le contraire sont malhonnêtes.

6) Commencer par les tests contraint trop l'écriture de l'application

> Dans tous les autres cas, commencer par les tests me créé un carcan manetal et technique qui me limite dans l'écriture de mon appli.

 J'ai eu cette impression au début, mais plus maintenant (comme dit plus haut, il y a un temps d'apprentissage non négligeable). Après, il est possible que certains personnes n'accrochent pas avec cette méthode. Encore une fois ca me paraît difficile de généraliser

7) Comment ecrire les tests si le code n'existe pas ?

> Sans compter qu'il faudra m'expliquer comment tu peux écrire tout tes tests sans code, sauf à mocker comme un fou tous les composants dont tu ne sais pas d'avance comment ils vont s'architecturer dans l'avenir.

Les mocks sont une solution, mais leur utilisation est beaucoup moins fastidieuse que ce que sous-entend cette phrase. Mocker le comportement d'un collaborateur, c'est 1 ou 2 lignes de code dans un test.

8) Dans 10 ans l'approche TDD sera définitivement oubliée (sauf pour critiquer le code legacy qui a été écrit en TDD)

> Mais, bon, s'il y en a pour qui ça marche, pas de soucis. On se revoit dans 10 ans !

 C'est possible. Le contraire aussi est possible. On sera probablement entre les deux avec des projets ayant réussis et des projets ayant échoués. Et il y a aura aussi des commentateurs de tous bords qui en tireront les conclusions qui les arrangent :-)

Nicolas Capponi

PS : pour ceux qui veulent un texte sérieux sur l'approche TDD, je vous conseille Growing Object Oriented Software Guided by Tests de Freeman et Pryce http://www.growing-object-oriented-software.com/

[Emmanuel Lécharny]

Le 7/22/12 3:54 PM, Nicolas Capponi a écrit :

>> j'en ai plus que marre d'entendre des théoriciens de l'informatique qui
> nous
>> expliquent à longueur de blog/tweet/O1-informatique que la secret de la
>> réussite d'un projet informatique, c'est d'écrire les tests d'abord, et
> que
>> le projet va magiquement se construire tout seul.
>> Non. Ce qui emmerde tut le monde avec TDD c'est que ça te fait croire
> qu'en écrivant les tests d'abord, tu vas magiquement rendre notre métier
> prédictif et industriel. C'est un leurre.
>
> Je pense qu'il faut séparer la critique du discours sur le TDD de la
> critique de la pratique elle-même.
> Ceux qui présentent ou vendent le TDD comme le truc magique qui résoud tous
> les problèmes jouent effectivement du pipeau. Ce ne seront ni les premiers,
> ni les derniers à le faire, lorsqu'une techno ou une pratique devient un
> buzzword on y a systématiquement droit.

On est d'accord. Encore une fois, je grossis le trait à outrance...

>
> Si on oublie tous les magiciens et qu'on s'intéresse à la pratique, quelles
> sont les critiques ?
>
> 1) Faire du TDD, c'est passer son temps à écrire des tests
>> Et non, tester, ce n'est pas coder. Tester, c'est tester. Je ne livre pas
> des tests à mettre en production, je livre une application, avec les tests
> qui vont avec.
>
>> Avec TDD, tu es censé inverser le process : tu commences par les tests,
> et avec un peu de chance, tu auras le temps de coder ton appli dans le
> temps qu'il te restera... Sur un projet un peu gros, je rigol d'avance ...
>
> Lorsqu'on fait du TDD, on n'écrit pas tous les tests d'un coup puis
> ensuite le code de l'appli. On écrit un test, puis le code, puis un autre
> test, puis le code.
> Donc au bout d'une heure par exemple, tu n'as pas que des tests, tu a bien
> écrit du code pour ton appli, qui partira en production. Et tu as les tests
> qui vont avec.
> Projet petit ou gros, tu ne repousse par l'écrire de ton appli à la fin.

Je ne suis pas d'accord. Je ne vois pas pourquoi commencer par un test
pourrait être un plus. Tout d'abord, cela suppose que tu sais ce que tu
dois tester, donc tu as déjà défini les spécifications de ta méthode. Le
fait d'avoir écrit le test d'abord fige cette méthode, et te pousse à ne
pas la modifier par la suite (sinon, tu risques d'avoir des dizaines de
tests à modifier). Ce n'est pas comme cela que l'on code dans la
pratique. Quand je code, et je pense que c'est la même chose pour la
majorité des personnes, j'ai une idée assez précise de là où je vais,
mais pas complètement. Je préfère me laisser une certaine latitude de
façon à avoir de la place pur de meilleures idées qui pourrait surgir en
cours de codage. Va peut paraître étrange, mais je pense que c'est une
liberté qui conduit à plus de souplesse et au final, à un mellieur code.

Bien évidemment, je rajoute les tests après, et j'essaye d'arriver à la
couverture fonctionnelle qui me semble utile pour l'applicaton en cours
de développement.

Je vais plus loin : il m'arrive souvent de 'penser' mes tests en
fonction du code que j'écris. Je me dis : "là, si on me passe telle
valeur ou telle valeur, il y a un risque que ça plante : va falloir
rajouter un test". Au final, comme ce sont de toutes façon des tests en
boîte blanche, je suis plus couvert que si j'avais fait mes tests en
amont et que si javais codé en fonction de mes tests.

Et surtout : je me suis focalisé sur le code de mon appli, et non pas
sur le code de mes tests. J'ai commencé par coder mon appli, quand tu
termines par cela (même si tu as l'impression de progresser dans ton
appli au fur et à mesure que tu écris tes tests, tu progresses juste
dans la couverture fonctionnelle de tes tests)

>
>
> 2) L'approche TDD est stupide
> Argument gratuit, sans plus de précisions je ne vois pas ce qu'on pourrait
> répondre.

Bien sûr que c'est gratuit. Mais je maintiens cette affirmation. En
fait, qu'on me prouve que c'est intelligent, et que ça améliore la
qualité du code produit, comparativement à une méthode naturelle. Ca me
rappelle la méthode globale qui a été enseignée dans les écoles
françaises dans les années 1970 (dieu merci, j'y ai échappé), et qui a
mené des millions de petits écoliers à perdre leur orthographe. Ce n'est
pas parce qu'une méthodologie est nouvelle qu'elle est plus
intelligente.La meilleure preuve en est que cette "méthodologie" a été
'réinventée' en 2003 et qu'elle n'a pas remplacée les méthodes
existantes, malgré 9 ans de marketing...

Sinon, je te renvoie à
http://en.wikipedia.org/wiki/Test-driven_development#Shortcomings. Bien
évidemment, toutes ces limitations s'appliquent stricto sensu aux tests
unitaires, mais au moins, on ne base pas les développements des
applications sur la base de prémisses qui sont faux.

>
> 3) L'approche TDD est infantilisante
> C'est un reproche fait au discours autour du TDD (et que je trouve valide
> comme dit plus haut). En soi je ne vois pas en quoi la pratique elle-même
> est infantilisante.

Le vrai problème de TDD est qu'elle suppose que l'on doit écrire du code
simple, qui doit être utile (KISS et YAGNI). Je suis pour que le code
soit le plus simple possible, mais ce n'est pas un prérequis. C'est
juste une conséquence d'une analyse du problème bien posée, et d'une
reflexion sur l'architecture du code. Un code devient compliqué
(j'insiste sur 'compliqué' en opposition à 'complexe' : on peut être
obligé d'écrire du code complexe) quand il est construit sans réelle
réflexion globale.

En conduisant les développeurs à penser leurs tests d'abord, on abouti à
un processus où ils vont écrire leur code en fonction d'un test, puis le
modifier en fonction d'un second, etc. Au final, on aura une sorte de
mille-feuilles qui sera la résultat de dizaines d'itérations sur les tests.

Mais comme on insiste pour que le développeur travaille de cette façon,
on lui nie toute capacité à comprendre le problème dans sa globalité :
c'est une négation de sa responsabilité, ce que j'appelle de
l'infantilisation.

>
> 4) L'approche TDD est contre-productive
> L'expérience que j'en ai est positive de ce point de vue. J'ai constaté
> une amélioration (forcément subjective) de la qualité de code produit.

Quelle taille d'application ? Quelle type d'application ? Quelle
complexité d'application ? Quelle taille d'équipe ?

Je suis sûr que pour certains projets, assez simples, avec une équipe
petite, TDD peut s'avérer efficace. Comme je l'ai écrit dans de mes
mails précédent, il m'arrive d'écrire mes tests avant d'écrire le code,
mais simplement dans le cas où je définis une API 'grand public', qui
est spécifiée précisément (pas de variation de l'API), et parce que je
veux être sûr que je n'aurais pas de trou dans ma raquette (et ça me
prend un temps non négligeable, quand je vais avoir 99% des tests qui
seront bons).

> Mais je me garderais bien de généraliser et de prétendre que c'est tout le
> temps le cas, en fonction des types d'applis et contextes, de l'équipe.
> Les quelques études scientifiques existantes sont apparemment contrastées
> (cf par exemple http://referentiel.institut-agile.fr/tdd.html, au bas de la
> page)
> La conclusion, c'est qu'il aussi abusif d'affirmer aujourd'hui que c'est
> la "silver bullet" que d'affirmer que ça ne fonctionne jamais.

Je dis simplement que c'est une méthode qui est basée sur l'intuition
d'une personne, qui par ailleurs a passé plus de temps à se focaliser
sur comment écrire du code qu'à en écrire lui-même, sans avoir fait ses
preuves.

Je n'ai pas connaissance d'un seul projet de taille raisonnable qui ait
été un succès basé sur du TDD (je parle de projet de plus de quelques
centaines de milliers de lignes de code)

je pense que c'est un gadget pour chefs de projets en manque de
nouveautés et pour consultants en manque d'argent.

Je pense qu'on impose cette méthodologie aux jeunes développeurs pour
s'assurer qu'ils pondent leurs tests, comme les poules pondent leurs oeufs.

bref, c'est punitif, castrateur, débilitant, simpliste, donc stupide.

>
> 5) L'application sera écrite en fonction des tests plutôt que du besoin
>> Tu designes des tests, pas une appli. Du coup, ton appli sera écrite en
> focntion de tes tests, et non en fonction de ton besoin. C'ets juste
> aberrant.
>
> Uh ? Les tests sont juste une technique qui te permet d'écrire ton appli

Et bien c'est stupide. C'est mettre la charrue avant les boeufs.

> (ta classe en fait puisqu'on parle de test U) d'un point de vue externe
> plutôt qu'interne. Et le design des tests est suffisamment
> contraint pour ne pas te dérouter du design de ton appli. Pour le coup, tu
> exprimes ton besoin - quel rôle joue l'objet, quelle interface il expose ?
> - avant de te lancer dans l'implémentation.

Désolé, mais je n'ai pas besoin de tests pour 'exprimer mon besoin'. Le
mec qui pense que les tests l'aide à exprimer son besoin, j'ai un doute
sur sa compréhension du métier d'informaticien...

> Cela nécessite un certain entraînement au début car on n'a pas l'habitude.

Bien sûr ! Marcher à l'envers aussi, ce n'est pas facile...

> Ce qui explique aussi qu'on perd en productivité lorsqu'on commence
> l'approche TDD, ceux qui disent le contraire sont malhonnêtes.

Et je pense même qu'on ne va pas plus vite avec de l'expérience. Avec
tous les problèmes qui viennent avec une démarche qui va à l'encontre
des principes mêmes du développement.

>
> 7) Comment ecrire les tests si le code n'existe pas ?
>> Sans compter qu'il faudra m'expliquer comment tu peux écrire tout tes
> tests sans code, sauf à mocker comme un fou tous les composants dont tu ne
> sais pas d'avance comment ils vont s'architecturer dans l'avenir.
> Les mocks sont une solution, mais leur utilisation est beaucoup moins
> fastidieuse que ce que sous-entend cette phrase. Mocker le comportement
> d'un collaborateur, c'est 1 ou 2 lignes de code dans un test.

Non. Dans les cas simples seulement. Dès que tu dois simuler une
connexion SGBDD, réseau ou autre, ton mock va être complexe.

>
> 8) Dans 10 ans l'approche TDD sera définitivement oubliée (sauf pour
> critiquer le code legacy qui a été écrit en TDD)
>> Mais, bon, s'il y en a pour qui ça marche, pas de soucis. On se revoit
> dans 10 ans !
> C'est possible. Le contraire aussi est possible. On sera probablement
> entre les deux avec des projets ayant réussis et des projets ayant échoués.
> Et il y a aura aussi des commentateurs de tous bords qui en tireront les
> conclusions qui les arrangent :-)
>
> Nicolas Capponi
> PS : pour ceux qui veulent un texte sérieux sur l'approche TDD, je vous
> conseille Growing Object Oriented Software Guided by Tests de Freeman et
> Pryce http://www.growing-object-oriented-software.com/

" Test-Driven Development (TDD) is now an established technique for
delivering better software faster"

Affirmation gratuite.

Freeman, c'est un mec qui se déclare comme "senior developer" au bout de
2 ans sur linkedin, et qui a passé le reste de sa carrière comme "coach"
et consultant. Ca me fait doucement rigoler... Par contre il a bossé
pour thougtwork, comme Nat Pryce. Bref, je suis plus que sceptique sur
leur compétence en tant que codeurs, par contre je suis intimmement
persuadé qu'ils sont très très fort pour vendre leur soupe...


Sur ce, je retourne à mes tests, j'en ai plein à coder pour vérifier que
ce que j'ai écrit fonctionne. Et merveille des merveille, ça me permet
de trouver des bugs, et de les corriger !

[Altus34]

2012/7/21 Emmanuel Lécharny <elec...@gmail.com>

Le 7/21/12 5:44 PM, Altus34 a écrit :

  j'en ai plus que marre d'entendre des théoriciens de l'informatique qui
nous expliquent à longueur de blog/tweet/O1-informatique que la secret de
la réussite d'un projet informatique, c'est d'écrire les tests d'abord, et
que le projet va magiquement se construire tout seul.

=> On est tous d'accord avec ca. La qualité des hommes sur un projet est
l'élément numéro 1 ;)

C'est équivalent à penser qu'un constructeur automobile va d'abord imaginer
ses crash tests, et construire sa voiture en fonction des crash tests.

=> Mauvaise annalogie un crash test n'est pas un test unitaire ;) ca serait
plus un test de résistance ou de montée en charge ;)

Je parle de crash tests, mais hier, j'ai discuté avec un collègue dont le cousin bosse sur des calculateurs embarqués. Ils font 7 heures de tests sur ces éléments une fois ceux-ci produit. 9a parait effectivement assez sain pour des éléments qui se trouvent dans un avion...

Malgré tout, ces tests sont constitués en partie à partir des spécifications, et en partie suite aux erreurs détectées. Finalement, un peu comme ce que l'on fait : on a des specs, donc on sait ce que l'on doit tester, et quand on détecte un bug, on rajoute un test.

De surcroit, il s'agit de tests en boîte noire, pas de tests en boîte blanche. Nous, ce sont les tests en boîtes blanches qui nous intéressent au premier chef, et désolé, mais sauf cas d'espèce (ie API), essayer d'imaginer tous les tests avant de développer c'est essayer mettre la charrue avant les boeufs.

Dans ma pratique quotidienne du TDD je n'imagine pas tous les tests ni ne les écrit au départ.

J'exprime tout dabord une intention business. Je code le test associé à cette intention en codant le test qui ne compile pas -> je fait compiler mon test -> donc j'écris mon code métier (celui qui est shippable). Le test fail ... j'écris le code métier qui réalise mon intention businness -> mon test pass.

Donc l'exercice finit j'ai du code de test ET mon code de prod. Ensuite je continu ce cycle la pour finalement exprimer en code ce que les requirement qui me sont fournis me demande (la plupart des noms de mes tests sont de type business). Et c'est la qu'entre en jeux la magie du TDD. Pendant que j'écris mes tests et mon code je m'appercois que certains test brisent => j constate très en amon ce que TOUT développeur vie => La spec est incomplète voir contient des incohérence. 

 

Justement les gars dans l'industrie il ne font QUE ca tester avant de
produire. Ils simulent avec leurs outils informatique 100 fois la pièce
Ils testent sont aérodynamisme, résistance .... en simluation virtuel puis
seulement apres fabrique la pièce (et encore parfois même pas dans le
materiaux final)
Bref ils unit test pièce par pièce,  composant par composant, module par
module pour au final assembler un  vrai premier prototype.

Il y a un petit point que tu omets de dire, et qui fait toute la différence : dans l'industrie, ils produisent à plus d'une unité. Par ailleurs, leurs outils de modélisations s'appliquent sur des éléments tangibles, pas nous.

Non tu as raté le VRAI point. Notre industrie et une industrie qui produit un bien IMMATERIEL. Les gars dans l'industrie leur gros problème c'est de produire à grande echelle un élement tangible et qui est régis / contraint par des lois physique en premier lieu. On ne construit pas un bateau comme un avion et le gars qui construit un bateau demain il va pas se mettre a construire des avions.

Nous en informatique nous modélisont des PROCESSUS intellectuel. Ce qui etait vrai hier n'est plus vrai aujourd'hui. On est obligé au cour de notre carrière de toucher à plusieur monde, banque , assurance, robotique, medicale... Souvent, sur les projets ou j'arrive, je ne connais pas le métier de mon client. Il me faut plus que l'apprendre il me faut me l'approprier.

La pratique du TDD me permet de RAPIDEMENT saisir le métier de mon client car je le manipule au travers de mon code. Je réflechis dessus.

Aucune documentation ne remplacera cet exercice la. Je suis souvent resortis de chez mes clients avec une meilleur connaissance business que pas mal de personnes chez eux. Car moi au lieu de lire des word et prendre ca pour verité j'ai manipulé profondement au travers de ma pratique de TDD leur domain d'affaire.

Comme on apprends pas le foot ou a devenir medecin dans des livres mais en PRATIQUANT, on ne peut exprimer un besoin dans un domain d'affaire si on ne le pratique pas....

Ne pas faire de test unitaire c'est comme designer une voiture ou il faut
refabriquer le moteur à chaque fois q'un petit élément à changé.

je n'ai jamais dit qu'il ne fallait pas faire de tests unitaire. Par contre, je trouve l'approche TDD complètemet stupide, infantilisante et contre-productive.

Aucune argumentation je met ca direct dans mon trash

 

Pour moi le gros problème du TDD et c'est ce qui emmerde TOUT le monde
c'est qu'il révèle que notre industrie est une industrie disfonctionel ou
max.

Non. Ce qui emmerde tut le monde avec TDD c'est que ça te fait croire qu'en écrivant le stests d'abord, tu vas magiquement rendre notre métier prédictif et industriel. C'est un leurre.

Justement comme il n'est pas prédictif il faut s'attacher à des pratiques qui nous maintienne toujours en maitrisse de notre code.

 

La seule et unique raison pour laquelle TDD a eu du succès, c'est parce que cela force les développeurs à ECRIRE DES TESTS. Si on attend qu'ils le fassent à la fin du projet, on est toujours à court de temps, du coup on livre à l'arrache, en espérant que ça marchera. Avec TDD, tu es censé inverser le process : tu commences par les tests, et avec un peu de chance, tu auras le temps de coder ton appli dans le temps qu'il te restera... Sur un projet un peu gros, je rigol d'avance ...

On est toujours a cours de temps en informatique. Quand je me fait des retrospectives sur mes projets je me dis que c'est jamais le codage (de test ou non) qui m'a fait perdre le plus de temps mais tout simplement le changement de requirement et autre spec de 600 pages illisibles, incomprehensible et tout ces manager qui te fond perdre ton temps en réunion car ile ne comprenne pas pourquoi on est pas capable de réaliser ce qui a été ecrit dans la doc de spec sans que leur cerveau n'arrive a concevoir que leur spec.

 1 - Elle ne s'execute pas (et oui c'est le code qui s'execute jusqu'a preuve du contraire)

 2 - Elle est tout simplement plein d'incoherence.

 

On pense encore que les dev sont les gars sur la chaine de montage alors
qu'elle n'existe pas en informatique cette chaine de montage.

Aujourd'hui quand je fait du TDD je réalise plusieurs activitée : design,
coding, testing, documentation, infra.

Tu designes des tests, pas une appli. Du coup, ton appli sera écrite en focntion de tes tests, et non en fonction de ton besoin. C'ets juste aberrant.

Non je ne design pas des test. J'exprime dans mes test mes requirements. Donc mon appli est écrite en fonction des besoins.

C'est juste aberrant de ne pas le comprendre ;)

 

Désolé, je code ET j'écrit des tests unitaires, il m'arrive même de définir mes tests unitaires avant de coder mon appi, mais uniquement dans le cas d'une API qui sera exposé à un publique large, donc je me couvre au maximum dans ce cas (et on s'approche d'une vision industrielle). Mais dans ce cas précis, mon API est déjà parfaitement décrite, et laisse peu de place à l'improvisation.

Dans tous les autres cas, commencer par les tests me créé un carcan manetal et technique qui me limite dans l'écriture de mon appli.

Mais ton code sera exposé a un public large de développeur de toute facon (désolé mais ton code vivra bien apres toi;))

Les test bien fait son la meilleur documentation.

 

Sans compter qu'il faudra m'expliquer comment tu peux écrire tout tes tests sans code, sauf à mocker comme un fou tous les composants dont tu ne sais pas d'avance comment ils vont s'architecturer dans l'avenir.

Cf plus haut 

 

TDD, c'est une vue de l'esprit vendu par des consultants à des DI en mal de sécurisation, et qui pensent que parce que les tests sont écrit avant, alors les applis seront correctes. Bullshit.

Mais, bon, s'il y en a pour qui ça marche, pas de soucis. On se revoit dans 10 ans !

Ou ca sur la place des grand homme ?

 

--
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.

[Emmanuel Lécharny]

Le 7/22/12 6:04 PM, Altus34 a écrit :

Si tes specs sont incomplètes, voire fausses, alors je ne vois pas sur
quoi tu te bases pour pondre tes tests. Il y a quelque chose qui cloche
dans ton raisonnement.

Les tests ne permettent pas de valider les spécifications, juste de
valider que le code pondu sur la base de spécifications est valide.

En consé"quence, pondre des tests sur la base de spécification te permet
juste de pondre du code invalide, et dans le meilleur des cas, de t'en
rendre compte quand les tests sont exécutés. Et là, tu commences à
réflechir au pourquoi de l'echec du test, quand tu aurais déjà constaté
l'nvalidité des spécifications à l'écriture du code.

>
>
>>
>>> Justement les gars dans l'industrie il ne font QUE ca tester avant de
>>> produire. Ils simulent avec leurs outils informatique 100 fois la pièce
>>> Ils testent sont aérodynamisme, résistance .... en simluation virtuel puis
>>> seulement apres fabrique la pièce (et encore parfois même pas dans le
>>> materiaux final)
>>> Bref ils unit test pièce par pièce, composant par composant, module par
>>> module pour au final assembler un vrai premier prototype.
>>>
>> Il y a un petit point que tu omets de dire, et qui fait toute la
>> différence : dans l'industrie, ils produisent à plus d'une unité. Par
>> ailleurs, leurs outils de modélisations s'appliquent sur des éléments
>> tangibles, pas nous.
>
> Non tu as raté le VRAI point. Notre industrie et une industrie qui produit
> un bien IMMATERIEL. Les gars dans l'industrie leur gros problème c'est de
> produire à grande echelle un élement tangible et qui est régis / contraint
> par des lois physique en premier lieu. On ne construit pas un bateau comme
> un avion et le gars qui construit un bateau demain il va pas se mettre a
> construire des avions.

je crois que c'est EXACTEMENT ce que j'ai dit plus haut.

>
> Nous en informatique nous modélisont des PROCESSUS intellectuel. Ce qui
> etait vrai hier n'est plus vrai aujourd'hui.

uh ?

> On est obligé au cour de notre
> carrière de toucher à plusieur monde, banque , assurance, robotique,
> medicale... Souvent, sur les projets ou j'arrive, je ne connais pas le
> métier de mon client. Il me faut plus que l'apprendre il me faut me
> l'approprier.

Je n'en disconviens pas. je ne vois pas ce en quoi la pratique de TDD va
t'y aider...

>
> La pratique du TDD me permet de RAPIDEMENT saisir le métier de mon client
> car je le manipule au travers de mon code. Je réflechis dessus.

Parce que tu penses qu'on ne réfléchis pas avant de pondre du code ?

> Aucune documentation ne remplacera cet exercice la. Je suis souvent
> resortis de chez mes clients avec une meilleur connaissance business que
> pas mal de personnes chez eux. Car moi au lieu de lire des word et prendre
> ca pour verité j'ai manipulé profondement au travers de ma pratique de TDD
> leur domain d'affaire.

Tes tests, encore une fois, viennent de spécifications fournies par ton
client. Autrement dit, du word, etc.

Nothing new under the sun.

>
> Comme on apprends pas le foot ou a devenir medecin dans des livres mais en
> PRATIQUANT, on ne peut exprimer un besoin dans un domain d'affaire si on ne
> le pratique pas....

Tu n'es pas censé exprimer un besoin. Ton client, si.Après, si tu bosses
avec des clients qui ne sont pas capable d'exprimer leur besoin (a
minima), je suis inquiet...

>
>
>>> Ne pas faire de test unitaire c'est comme designer une voiture ou il faut
>>> refabriquer le moteur à chaque fois q'un petit élément à changé.
>>>
>> je n'ai jamais dit qu'il ne fallait pas faire de tests unitaire. Par
>> contre, je trouve l'approche TDD complètemet stupide, infantilisante et
>> contre-productive.
>>
>>
> Aucune argumentation je met ca direct dans mon trash

C'est vrai, c'est un peu lapidaire. J'ai développé dans un autre mail.
(il faut que je me force à argumenter...)

>
>
>>> Pour moi le gros problème du TDD et c'est ce qui emmerde TOUT le monde
>>> c'est qu'il révèle que notre industrie est une industrie disfonctionel ou
>>> max.
>>>
>> Non. Ce qui emmerde tut le monde avec TDD c'est que ça te fait croire
>> qu'en écrivant le stests d'abord, tu vas magiquement rendre notre métier
>> prédictif et industriel. C'est un leurre.
>>
> Justement comme il n'est pas prédictif il faut s'attacher à des pratiques
> qui nous maintienne toujours en maitrisse de notre code.

Pipeau de consultant. Sous prétexte que le métier qui est le nôtre n'est
pas prédictif (c'est de l'artisanat, chaque projet est différent), il
faudrait mettre en oeuvre des pratiques "magiques" qui nous permettrait
de magiquement sortir du moule un projet en temps, fonctionalités et
coût pré-définit. Le problème, c'est que des méthodes magiques comme
celle-là, ça fait juste 25 ans qu'on m'en parle, et qu'on me bassine
régulièrement avec ces conneries à 2500€ la journée de formation.
Maintenant, j'attend qu'on me PROUVE qu'il y a un gain mesuré et
reproductible. Au jour d'aujourd'hui, aucune étude n'a démontrée un
avantage qualitatif ou quantitatif lié TDD (ou à une autre
méthodologie). Je pense même que c'est nuisible...

>
>
>> La seule et unique raison pour laquelle TDD a eu du succès, c'est parce
>> que cela force les développeurs à ECRIRE DES TESTS. Si on attend qu'ils le
>> fassent à la fin du projet, on est toujours à court de temps, du coup on
>> livre à l'arrache, en espérant que ça marchera. Avec TDD, tu es censé
>> inverser le process : tu commences par les tests, et avec un peu de chance,
>> tu auras le temps de coder ton appli dans le temps qu'il te restera... Sur
>> un projet un peu gros, je rigol d'avance ...
>>
>> On est toujours a cours de temps en informatique. Quand je me fait des
> retrospectives sur mes projets je me dis que c'est jamais le codage (de
> test ou non) qui m'a fait perdre le plus de temps mais tout simplement le
> changement de requirement et autre spec de 600 pages illisibles,
> incomprehensible et tout ces manager qui te fond perdre ton temps en
> réunion car ile ne comprenne pas pourquoi on est pas capable de réaliser ce
> qui a été ecrit dans la doc de spec sans que leur cerveau n'arrive a
> concevoir que leur spec.
>
> 1 - Elle ne s'execute pas (et oui c'est le code qui s'execute jusqu'a
> preuve du contraire)
> 2 - Elle est tout simplement plein d'incoherence.

So what ? TDD va magiquement résoudre ce problème ?

>
>
>> On pense encore que les dev sont les gars sur la chaine de montage alors
>>> qu'elle n'existe pas en informatique cette chaine de montage.
>>>
>>> Aujourd'hui quand je fait du TDD je réalise plusieurs activitée : design,
>>> coding, testing, documentation, infra.
>>>
>> Tu designes des tests, pas une appli. Du coup, ton appli sera écrite en
>> focntion de tes tests, et non en fonction de ton besoin. C'ets juste
>> aberrant.
>>
> Non je ne design pas des test. J'exprime dans mes test mes requirements.

Non. Les requirements de TES clients. Avec leurs erreurs.

> Donc mon appli est écrite en fonction des besoins.
> C'est juste aberrant de ne pas le comprendre ;)

C'est toujours vrai, TDD ou pas. Où est le problème ?

>
>
>> Désolé, je code ET j'écrit des tests unitaires, il m'arrive même de
>> définir mes tests unitaires avant de coder mon appi, mais uniquement dans
>> le cas d'une API qui sera exposé à un publique large, donc je me couvre au
>> maximum dans ce cas (et on s'approche d'une vision industrielle). Mais dans
>> ce cas précis, mon API est déjà parfaitement décrite, et laisse peu de
>> place à l'improvisation.
>>
>> Dans tous les autres cas, commencer par les tests me créé un carcan
>> manetal et technique qui me limite dans l'écriture de mon appli.
>>
> Mais ton code sera exposé a un public large de développeur de toute facon
> (désolé mais ton code vivra bien apres toi;))
> Les test bien fait son la meilleur documentation.

Je n'ai jamais dit le contraire. J'aime les tests, j'adore les tests.
Quand mes utilisateurs me demande coment faire ceci ou cela, je les
renvoie sur les tests unitaires pour qu'ils puissent comprendre la
logique d'utilisation. Quand un nouveau venu me demande comment il
pourrait participer aux projets auxquels je participent, je leur
indiquent qu'ils doivent d'abord commencer par regarder dans le bug
tracker, chosir un bug qu'ils voudraient corriger, et partir d'un test.
S'il veulent rentrer dans une partie du code, je les pointent sur les
tests unitaires associés. Et j'ai de la matière, avec plus de 5000 tests !

Mais en aucun cas je ne pratique ni ne pratiquerai TDD.

>
>> TDD, c'est une vue de l'esprit vendu par des consultants à des DI en mal
>> de sécurisation, et qui pensent que parce que les tests sont écrit avant,
>> alors les applis seront correctes. Bullshit.
>>
>> Mais, bon, s'il y en a pour qui ça marche, pas de soucis. On se revoit
>> dans 10 ans !
>
> Ou ca sur la place des grand homme ?

Rahhh, Cabrel, sort de ce corps, on t'a reconnu, tu veux te faire passer
pour Bruel !

"Je fais du TDD, encore et encore..."

[tvi...@onyme.com]

On Sun, 22 Jul 2012 12:04:17 -0400, Altus34 <alt...@gmail.com> wrote:
> 2012/7/21 Emmanuel Lécharny

Désolé mais tu n'es pas "très en amont" là: tu es déjà en train de
produire du code. Tout développeur DOIT voir qu'une spec est incohérente
ou incomplète au minimum au moment où il développe. Qu'il fasse du TDD
ou non, c'est le plus tard possible en fait. Sinon il est incompétent et
failli à son devoir de conseil et livre un truc incohérent. L'idéal est
de le voir encore plus tôt, en lisant la specs quand il essaye de la
comprendre.

Moi cela m'est arrivé plein de fois de constater des incohérence de
specs sans faire de TDD. De ce côté, le TDD n'apporte rien.

Pareil, c'est une obligation de connaître le métier du client mieux que
lui (devoir de conseil on en a déjà parlé).
Le client va souvent t'exposer SA solution pour répondre au besoin et
non le besoin lui même. Il faut souvent remonter au besoin, démêler les
croyances, des vrais processus pour enfin pondre specs et code afin
d'offrir la solution valable avec valeur ajoutée.
Encore une fois le TDD n'apporte rien.

Je rejoins Emmanuel L. sur le TDD, parce que je pense que cette
pratique force à voir les choses par le petit bout de la lorgnette et
empêche d'appréhender le besoin et l'application de manière systémique.
C'est très motivant à la fin de la journée d'avoir ajouté X tests et X
traitement à l'application et on recommence le lendemain. On empile des
tests qui valident des opérations unitaires mais à quel moment se
demandent-on si tous ces tests verts sont cohérents par rapport au
besoin de mon client?

Après si tu arrives à appréhender le besoin de ton client et à jouer
ton rôle de conseil en écrivant des tests je dis OK.

Le TDD doit simplement être vu comme une pratique de "développement"
comme une autre (pas meilleure, ni moins bien). Mais pas comme une
méthode de production de logiciel car elle ne couvre pas ce dont tu
parles: saisir le métier, spécifier ...



>
> [...] (zzzzzzz)

>  
> TDD, c'est une vue de l'esprit vendu par des consultants à des DI
> en mal de sécurisation, et qui pensent que parce que les tests sont
> écrit avant, alors les applis seront correctes. Bullshit.

Par contre, je diverge d'Emmanuel L. Tu as trop tendances à prendre
tous les gens qui témoignent (sur cette liste en tout cas) comme des
naïfs endoctrinés par des consultants Gourou. Accordes nous le bénéfice
du doute ;-)
J'ai discuté avec un dev qui fait du TDD et ça l'éclate de développer
comme ça:
Si y en a que ça éclate de marcher à l'envers mais qu'ils arrivent
quand même au bureau le matin, moi je dis tant mieux alors.

>
> Mais, bon, s'il y en a pour qui ça marche, pas de soucis. On se
> revoit dans 10 ans !
>
> Ou ca sur la place des grand homme ?
>  
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

> www.iktek.com [2]

>
> --
> 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 [3].

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

> lescastcodeur...@googlegroups.com [4].

> Pour plus d'options, consultez la page de ce groupe :

> http://groups.google.com/group/lescastcodeurs?hl=fr [5]

>
> --
> 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
>
>

> Links:
> ------
> [1] mailto:elec...@gmail.com
> [2] http://www.iktek.com
> [3] mailto:lescast...@googlegroups.com
> [4] mailto:lescastcodeurs%2Bunsu...@googlegroups.com
> [5] http://groups.google.com/group/lescastcodeurs?hl=fr

[Emmanuel Lécharny]

Le 7/23/12 12:32 AM, tvi...@onyme.com a écrit :

> Pareil, c'est une obligation de connaître le métier du client mieux
> que lui (devoir de conseil on en a déjà parlé).

Désolé de te reprendre, mais ton devoir de conseil porte sur ton
expertise, pas sur celle de ton client. Généralement, et sauf exception,
quand tu commences un projet, tu connais moins bien le métier de ton
client...

>
>> [...] (zzzzzzz)
>>
>> TDD, c'est une vue de l'esprit vendu par des consultants à des DI
>> en mal de sécurisation, et qui pensent que parce que les tests sont
>> écrit avant, alors les applis seront correctes. Bullshit.
> Par contre, je diverge d'Emmanuel L. Tu as trop tendances à prendre
> tous les gens qui témoignent (sur cette liste en tout cas) comme des
> naïfs endoctrinés par des consultants Gourou. Accordes nous le bénéfice
> du doute ;-)

Non, non, ne t'inquiètes pas. Je pense simplement que l'on a affaire à
une sorte de Cargo Cult, dans le cas de 'trucs' comme TDD. Mais je suis
certain que la plupart des lecteurs savent ne pas rentrer dans ce type
de mode.

Bon, après, comme d'habitude, je force le trait ! ;)

[Thibaud Vibes]

Le 23/07/2012 00:43, Emmanuel Lécharny a écrit :
> Le 7/23/12 12:32 AM, tvi...@onyme.com a écrit :
>> Pareil, c'est une obligation de connaître le métier du client mieux
>> que lui (devoir de conseil on en a déjà parlé).
> Désolé de te reprendre, mais ton devoir de conseil porte sur ton
> expertise, pas sur celle de ton client. Généralement, et sauf
> exception, quand tu commences un projet, tu connais moins bien le
> métier de ton client...

Par expérience (même si elle n'est que de 8 ans), il te la faut sur
celle du client aussi. Etant "petit", je travaille pour des "petits" où
la DSI est inexistante (au propre comme au figuré). Quand le client
t'explique son besoin ou ses processus, c'est souvent n'importe quoi. A
combien de réunion j'ai assisté où le responsable d'un
service/departement/whatever nous présentait un processus et le
l'utilisateur pilote qui répondant: "mais nous on fait jamais comme ça!"
?? => s'en suit des débats animé (et c'est là que j'aurais aimé
connaître la boite à meuuh ;-) )
Donc il faut prendre le recul et analyser de manière transversale (ce
qu'aurait fait la DSI si elle était là) et proposer d'abord de bien
valider les processus et ensuite faire la spec de l'appli. Souvent quand
on débarque sur des projets un peu critique on est très structurant pour
le client (dans le cas de petits clients). On arrive avec nos têtes de
jeunes, notre esprit naïf et on pose les bonnes questions (normalement)

Si tu livres une appli qui ne répond pas au besoin mais qui est conforme
aux specs, tu n'as rien gagné. Au pire tu te retrouve au tribunal (comme
cela nous est arrivé, j'en ai parlé dans un autre thread).

[Emmanuel Lécharny]

Le 7/23/12 9:27 AM, Thibaud Vibes a écrit :

C'est tout le problème. Si ton client n'est pas structuré, tu vas faire
son informatique *ET* son expression de besoin à sa place. C'est un
métier, et ce n'est pas pour rien que beaucoup de grosses boîtes font
appel à de l'assistance à maîtrise d'ouvrage (métier qui consiste à
exprimer le besoin du client à la place du client).

En fait, dans ce cas, ton boulot consiste à *comprendre* le métier du
client, qui va souvent éluder les parties qui lui paraissent triviales,
pour te les signaler plus tard (trop tard) "Ah, mais dans ce cas, faut
faire comme ça, vous saviez pas ???"

D'où l'intérêt des spécifications, qui malheureusement ne sont pas lues
en entier, ou comprises en entier.

Mais c'est un autre débat, qui rentre dans le cadre du serpent de mer de
la "double compétence" (quelque chose dont on nous bassine depuis des
décennies en nous expliquant que l'ingénieur informaticien de dans 10
ans aura une double compétence - ou triple, quadruple...- ou ne sera pas).

C'est un combat jamais gagné...

[ehsavoie]

>>Le fait d'avoir écrit le test d'abord fige cette méthode, et te pousse à ne pas la modifier par la suite (sinon, tu risques d'avoir des dizaines de tests à modifier).

Ca c'est un énorme PIPEAU Manu car cela signifierait que tu ne fais
jamais un seul refactoring pour ne pas changer tes tests. Franchement
je n'y crois pas.
Même eclipse refacotre le code de test quand tu changes une methode :P
Le TDD n'impose pas de ne pas être intelligent ou de ne pas savoir
dans quelle direction tu vas, il te permet juste d'avoir un filet de
tests.

De toute façon ce qui compte c'est le truc entre le clavier et
l'écran, qu'il fasse des tests, en premier, en dernier peu importe,
mais qu'il en fasse de pertinents me suffit amplement.
----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

[Jeff MAURY]

Je dirais même que le fait d'avoir des dizaines de tests sous-jacents favorise le refactoring, tu te sens toujours plus sur quand tu fais des changements si tu sais que tu as toute une batterie de tests qui va vérifier ce que tu fais.

Jeff

2012/7/23 ehsavoie <emmanuel...@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 Lécharny]

Le 7/23/12 10:00 AM, Jeff MAURY a écrit :

> Je dirais même que le fait d'avoir des dizaines de tests sous-jacents
> favorise le refactoring, tu te sens toujours plus sur quand tu fais des
> changements si tu sais que tu as toute une batterie de tests qui va
> vérifier ce que tu fais.

C'est orthogonal. Le fait que des centaines de tests vérifient que ton
refactoring est correct est effectivement un plus. Mais cela n'implique
pas de s'appuyer sur du TDD.

Mon point de vue est qu'en se focalisant sur les tests en priorité
(TDD), tu cherches à limiter les modifications qui impactent tes tests
quand tu refactores, donc cela présente un risque de limitation de ton
application, ou pire, un surcoût s'il fat modifier une bance de tests à
chaque ajout fonctionnel.

Encore une fois, je le répète, je ne suis pas contre les tests, je ne
critique pas les tests, je récuse juste l'approche qui consiste à
*commencer* par les tests.

[Emmanuel Lécharny]

Le 7/23/12 9:56 AM, ehsavoie a écrit :

>>> Le fait d'avoir écrit le test d'abord fige cette méthode, et te pousse à ne pas la modifier par la suite (sinon, tu risques d'avoir des dizaines de tests à modifier).
> Ca c'est un énorme PIPEAU Manu car cela signifierait que tu ne fais
> jamais un seul refactoring pour ne pas changer tes tests. Franchement
> je n'y crois pas.
> Même eclipse refacotre le code de test quand tu changes une methode :P
> Le TDD n'impose pas de ne pas être intelligent ou de ne pas savoir
> dans quelle direction tu vas, il te permet juste d'avoir un filet de
> tests.

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

Si tu modifies les paramètres de ta méthode, le refactoring ne va pas
magiquement rajouté les vauers dans les tests qui invoque la méthode. Tu
vas devoir passer sur chacun des appels. Alors évidemment, si tu
renommes ta méthode, oui, ça marche.

Donc je maintiens que commencer par coder les tests te pousse à éviter
de refactorer quand cela risque d'impacter des centaines de tests.

>
> De toute façon ce qui compte c'est le truc entre le clavier et
> l'écran, qu'il fasse des tests, en premier, en dernier peu importe,
> mais qu'il en fasse de pertinents me suffit amplement.

On est d'accord. Sauf que je préfère utiliser le truc entre le clavier
et l'écran de façon plus intelligente...

[Nicolas Delsaux]

2012/7/23 Emmanuel Lécharny <elec...@gmail.com>:

>
> On est d'accord. Sauf que je préfère utiliser le truc entre le clavier et
> l'écran de façon plus intelligente...
>

Pfff ...

<troll>
marche pas, il est forcément débile
Nous ça fait longtemps qu'on l'a remplacé par un générateur à base de
réseaux de neurones qui utilise les tests pour générer le code (comme
ça on est sûr d'être compatibles YAGNI)
</troll>
--
Nicolas Delsaux

[Nicolas Capponi]

On 07/22/2012 05:59 PM, Emmanuel L�charny wrote:
> Le 7/22/12 3:54 PM, Nicolas Capponi a �crit :
>> Lorsqu'on fait du TDD, on n'�crit pas tous les tests d'un coup puis
>> ensuite le code de l'appli. On �crit un test, puis le code, puis un autre

>> test, puis le code.
>> Donc au bout d'une heure par exemple, tu n'as pas que des tests, tu a bien

>> �crit du code pour ton appli, qui partira en production. Et tu as les tests
>> qui vont avec.
>> Projet petit ou gros, tu ne repousse par l'�crire de ton appli � la fin.
>
> Je ne suis pas d'accord. Je ne vois pas pourquoi commencer par un test pourrait �tre un plus. Tout d'abord, cela
> suppose que tu sais ce que tu dois tester, donc tu as d�j� d�fini les sp�cifications de ta m�thode. Le fait d'avoir
> �crit le test d'abord fige cette m�thode, et te pousse � ne pas la modifier par la suite (sinon, tu risques d'avoir
> des dizaines de tests � modifier). Ce n'est pas comme cela que l'on code dans la pratique. Quand je code, et je pense
> que c'est la m�me chose pour la majorit� des personnes, j'ai une id�e assez pr�cise de l� o� je vais, mais pas
> compl�tement. Je pr�f�re me laisser une certaine latitude de fa�on � avoir de la place pur de meilleures id�es qui
> pourrait surgir en cours de codage. Va peut para�tre �trange, mais je pense que c'est une libert� qui conduit � plus
> de souplesse et au final, � un mellieur code.

Je ne suis pas d'accord avec le fait qu'on fige la m�thode, c'est m�me le contraire. Le cycle de TDD met explicitement
en avant le refactoring, autre fa�on d'exprimer le fait d'avoir "une certaine latitude de fa�on � avoir de la place pur
de meilleures id�es qui pourrait surgir en cours de codage". Les tests existants te �galement permettent d'avoir un
filet de protection sur tes changements.

>
> Bien �videmment, je rajoute les tests apr�s, et j'essaye d'arriver � la couverture fonctionnelle qui me semble utile
> pour l'applicaton en cours de d�veloppement.
>
> Je vais plus loin : il m'arrive souvent de 'penser' mes tests en fonction du code que j'�cris. Je me dis : "l�, si on
> me passe telle valeur ou telle valeur, il y a un risque que �a plante : va falloir rajouter un test". Au final, comme
> ce sont de toutes fa�on des tests en bo�te blanche, je suis plus couvert que si j'avais fait mes tests en amont et que
> si javais cod� en fonction de mes tests.
Je pense mes tests en fonction du code que je veux �crire. Je peux aussi rajouter des tests si je pense n'avoir pas
couvert certains cas.
>
> Et surtout : je me suis focalis� sur le code de mon appli, et non pas sur le code de mes tests. J'ai commenc� par
> coder mon appli, quand tu termines par cela (m�me si tu as l'impression de progresser dans ton appli au fur et �
> mesure que tu �cris tes tests, tu progresses juste dans la couverture fonctionnelle de tes tests)
>
Donc quand j'ai fini de coder, en fait je n'ai pas vraiment une appli ? Juste des bouts de code qui ne servent � rien ?
Heureusement les utilisateurs ne s'en sont pas aper�u !
Je ne comprend pas ce raisonnement.

>>
>>
>> 2) L'approche TDD est stupide

>> Argument gratuit, sans plus de pr�cisions je ne vois pas ce qu'on pourrait
>> r�pondre.
> Bien s�r que c'est gratuit. Mais je maintiens cette affirmation. En fait, qu'on me prouve que c'est intelligent, et
> que �a am�liore la qualit� du code produit, comparativement � une m�thode naturelle. Ca me rappelle la m�thode globale
> qui a �t� enseign�e dans les �coles fran�aises dans les ann�es 1970 (dieu merci, j'y ai �chapp�), et qui a men� des
> millions de petits �coliers � perdre leur orthographe. Ce n'est pas parce qu'une m�thodologie est nouvelle qu'elle est
> plus intelligente.La meilleure preuve en est que cette "m�thodologie" a �t� 'r�invent�e' en 2003 et qu'elle n'a pas
> remplac�e les m�thodes existantes, malgr� 9 ans de marketing...
Beau retournement de situation. Tu affirmes que quelque chose est stupide et c'est � ton interlocuteur de prouver le
contraire...
Sur le marketing, la nouveau produit qui lave plus blanc que l'ancien, j'ai d�j� dit ce que j'en pensais, mais ca ne
prouve rien ni dans un sens ni dans l'autre.
Java n'a pas remplac� C malgr� plus de 15 ans de marketing :-)

>
> Sinon, je te renvoie � http://en.wikipedia.org/wiki/Test-driven_development#Shortcomings. Bien �videmment, toutes ces
> limitations s'appliquent stricto sensu aux tests unitaires, mais au moins, on ne base pas les d�veloppements des
> applications sur la base de pr�misses qui sont faux.

Comme tu le dis, le fait d'avoir des tests unitaires vient avec son cort�ge de probl�mes, qu'il faut g�rer. Si on les
fait quand m�me c'est parce qu'on consid�re que cela apporte plus que �a ne co�te au final.
Le d�veloppement d'une appli n'est pas le d�roulement d'une preuve formelle, je n'adh�re pas � ton analogie sur les
pr�misses.

>
>>
>> 3) L'approche TDD est infantilisante
>> C'est un reproche fait au discours autour du TDD (et que je trouve valide

>> comme dit plus haut). En soi je ne vois pas en quoi la pratique elle-m�me
>> est infantilisante.
> Le vrai probl�me de TDD est qu'elle suppose que l'on doit �crire du code simple, qui doit �tre utile (KISS et YAGNI).
> Je suis pour que le code soit le plus simple possible, mais ce n'est pas un pr�requis. C'est juste une cons�quence
> d'une analyse du probl�me bien pos�e, et d'une reflexion sur l'architecture du code. Un code devient compliqu�
> (j'insiste sur 'compliqu�' en opposition � 'complexe' : on peut �tre oblig� d'�crire du code complexe) quand il est
> construit sans r�elle r�flexion globale.
>
> En conduisant les d�veloppeurs � penser leurs tests d'abord, on abouti � un processus o� ils vont �crire leur code en

> fonction d'un test, puis le modifier en fonction d'un second, etc. Au final, on aura une sorte de mille-feuilles qui

> sera la r�sultat de dizaines d'it�rations sur les tests.
>
> Mais comme on insiste pour que le d�veloppeur travaille de cette fa�on, on lui nie toute capacit� � comprendre le
> probl�me dans sa globalit� : c'est une n�gation de sa responsabilit�, ce que j'appelle de l'infantilisation.
Ok, �a c'est un argument qui me semble valide. C'est un risque effectivement, m�me si je ne suis jamais tomb� sur
l'effet mille-feuilles que tu d�cris.
En pratique, rien ne t'emp�che de r�fl�chir avant, pendant, apr�s, et d'adapter ce discours KISS/YAGNI au contexte de
ton appli.

Pour le c�t� infantilisant, cela suppose que tu suives religieusement la m�thode, sans ne jamais te poser de questions.
Mais dans ce cas, quelle que soit ta m�thode pour �crire du code, naturelle ou pas, je ne suis pas s�r qu'au final le
r�sultat soit tr�s bon.

>
>
>>
>> 4) L'approche TDD est contre-productive

>> L'exp�rience que j'en ai est positive de ce point de vue. J'ai constat�
>> une am�lioration (forc�ment subjective) de la qualit� de code produit.
> Quelle taille d'application ? Quelle type d'application ? Quelle complexit� d'application ? Quelle taille d'�quipe ?
>
> Je suis s�r que pour certains projets, assez simples, avec une �quipe petite, TDD peut s'av�rer efficace. Comme je
> l'ai �crit dans de mes mails pr�c�dent, il m'arrive d'�crire mes tests avant d'�crire le code, mais simplement dans le
> cas o� je d�finis une API 'grand public', qui est sp�cifi�e pr�cis�ment (pas de variation de l'API), et parce que je
> veux �tre s�r que je n'aurais pas de trou dans ma raquette (et �a me prend un temps non n�gligeable, quand je vais

> avoir 99% des tests qui seront bons).

1) Quelques milliers de ligne de code, web service, traitements sur des dizaine de milliers d'items avec des r�gles
m�tiers complexes, �quipe variant de 2 � 3 personnes, sur 5 mois
2) Quelques dizaines de milliers de lignes de code, processing/web services/back-office, traitements plus ou moins
complexes sur des millions d'items
, �quipe variant entre 5 et 7 personnes, sur plus de 18 mois

Les 2 applications sont en maintenance �volutive, plus ou moins active selon les besoins.

Sur la taille des �quipes et des applications, si ton architecture est suffisamment d�coupl�e et que le type d'appli le
permet, tu peux te permettre d'avoir de petites �quipes qui travaillent (relativement) ind�pendamment sur des parties
diff�rentes. C'est la cas dans ma bo�te. Je n'ai pas l'impression que cette situation soit exceptionnelle.

>
>> Mais je me garderais bien de g�n�raliser et de pr�tendre que c'est tout le
>> temps le cas, en fonction des types d'applis et contextes, de l'�quipe.
>> Les quelques �tudes scientifiques existantes sont apparemment contrast�es

>> (cf par exemple http://referentiel.institut-agile.fr/tdd.html, au bas de la
>> page)
>> La conclusion, c'est qu'il aussi abusif d'affirmer aujourd'hui que c'est

>> la "silver bullet" que d'affirmer que �a ne fonctionne jamais.
> Je dis simplement que c'est une m�thode qui est bas�e sur l'intuition d'une personne, qui par ailleurs a pass� plus de
> temps � se focaliser sur comment �crire du code qu'� en �crire lui-m�me, sans avoir fait ses preuves.
>
> Je n'ai pas connaissance d'un seul projet de taille raisonnable qui ait �t� un succ�s bas� sur du TDD (je parle de

> projet de plus de quelques centaines de milliers de lignes de code)

C'est s�r qu'avec une telle contrainte �a �limine pas mal de monde. Je pense que je n'ai jamais travaill� sur un projet
d'une telle taille (en supposant qu'on �limine tous les projets que l'on peut d�couper en sous-projets relativement
ind�pendants, o� une partie pourrait �tre r�alis�e en TDD). Et la plupart de ceux que je connais non plus.

>
> je pense que c'est un gadget pour chefs de projets en manque de nouveaut�s et pour consultants en manque d'argent.
>
> Je pense qu'on impose cette m�thodologie aux jeunes d�veloppeurs pour s'assurer qu'ils pondent leurs tests, comme les
> poules pondent leurs oeufs.
>
> bref, c'est punitif, castrateur, d�bilitant, simpliste, donc stupide.
OK, c'est bon, je crois que j'ai bien compris cette partie l� de ton argumentation :-)

>
>>
>> 5) L'application sera �crite en fonction des tests plut�t que du besoin
>>> Tu designes des tests, pas une appli. Du coup, ton appli sera �crite en

>> focntion de tes tests, et non en fonction de ton besoin. C'ets juste
>> aberrant.
>>

>> Uh ? Les tests sont juste une technique qui te permet d'�crire ton appli

>
> Et bien c'est stupide. C'est mettre la charrue avant les boeufs.
>> (ta classe en fait puisqu'on parle de test U) d'un point de vue externe

>> plut�t qu'interne. Et le design des tests est suffisamment
>> contraint pour ne pas te d�router du design de ton appli. Pour le coup, tu
>> exprimes ton besoin - quel r�le joue l'objet, quelle interface il expose ?
>> - avant de te lancer dans l'impl�mentation.
>
> D�sol�, mais je n'ai pas besoin de tests pour 'exprimer mon besoin'. Le mec qui pense que les tests l'aide � exprimer
> son besoin, j'ai un doute sur sa compr�hension du m�tier d'informaticien...

Stupide, ne comprend pas le m�tier d'informaticien, .... Paradoxalement, pour quelqu'un qui n'aime pas la m�thode
globale, tu es assez globalisant dans tes propos !

>> Cela n�cessite un certain entra�nement au d�but car on n'a pas l'habitude.
>
> Bien s�r ! Marcher � l'envers aussi, ce n'est pas facile...
>> Ce qui explique aussi qu'on perd en productivit� lorsqu'on commence
>> l'approche TDD, ceux qui disent le contraire sont malhonn�tes.
>
> Et je pense m�me qu'on ne va pas plus vite avec de l'exp�rience. Avec tous les probl�mes qui viennent avec une
> d�marche qui va � l'encontre des principes m�mes du d�veloppement.

>>
>> 7) Comment ecrire les tests si le code n'existe pas ?

>>> Sans compter qu'il faudra m'expliquer comment tu peux �crire tout tes
>> tests sans code, sauf � mocker comme un fou tous les composants dont tu ne

>> sais pas d'avance comment ils vont s'architecturer dans l'avenir.
>> Les mocks sont une solution, mais leur utilisation est beaucoup moins
>> fastidieuse que ce que sous-entend cette phrase. Mocker le comportement
>> d'un collaborateur, c'est 1 ou 2 lignes de code dans un test.

> Non. Dans les cas simples seulement. D�s que tu dois simuler une connexion SGBDD, r�seau ou autre, ton mock va �tre
> complexe.
Tu ne les simules pas. Dans la cas d'une connexion SGBD, tu mockes ton DAO (ou interface d'acc�s � ta base que tu
appelles comme tu veux) pour valider que les appelants fonctionnent correctement (cas nominaux + cas d'erreurs) et tu
fais un test d'int�gration pour v�rifier que ton DAO fonctionne bien avec ton SGBD.
>>
>> 8) Dans 10 ans l'approche TDD sera d�finitivement oubli�e (sauf pour
>> critiquer le code legacy qui a �t� �crit en TDD)
>>> Mais, bon, s'il y en a pour qui �a marche, pas de soucis. On se revoit

>> dans 10 ans !
>> C'est possible. Le contraire aussi est possible. On sera probablement

>> entre les deux avec des projets ayant r�ussis et des projets ayant �chou�s.

>> Et il y a aura aussi des commentateurs de tous bords qui en tireront les
>> conclusions qui les arrangent :-)
>>
>> Nicolas Capponi

>> PS : pour ceux qui veulent un texte s�rieux sur l'approche TDD, je vous

>> conseille Growing Object Oriented Software Guided by Tests de Freeman et
>> Pryce http://www.growing-object-oriented-software.com/
>
> " Test-Driven Development (TDD) is now an established technique for delivering better software faster"
>
> Affirmation gratuite.

Effectivement

>
> Freeman, c'est un mec qui se d�clare comme "senior developer" au bout de 2 ans sur linkedin, et qui a pass� le reste
> de sa carri�re comme "coach" et consultant. Ca me fait doucement rigoler... Par contre il a boss� pour thougtwork,
> comme Nat Pryce. Bref, je suis plus que sceptique sur leur comp�tence en tant que codeurs, par contre je suis
> intimmement persuad� qu'ils sont tr�s tr�s fort pour vendre leur soupe...
Je n'adh�re pas � ce genre d'arguments. D'autant que les meilleurs codeurs ne sont pas forc�mment les plus � m�me
d'expliquer leur m�thode.
Bref, j'ai trouv� ce bouquin int�ressant, et je le conseille � ceux que le TDD ne rebute pas.

>
>
> Sur ce, je retourne � mes tests, j'en ai plein � coder pour v�rifier que ce que j'ai �crit fonctionne. Et merveille
> des merveille, �a me permet de trouver des bugs, et de les corriger !
>
>
Je retourne � mon code.
Rendez-vous � une prochaine discussion !

[Emmanuel Lécharny]

Le 7/23/12 6:26 PM, Nicolas Capponi a écrit :
> On 07/22/2012 05:59 PM, Emmanuel Lécharny wrote:
>> Le 7/22/12 3:54 PM, Nicolas Capponi a écrit :
>>> Lorsqu'on fait du TDD, on n'écrit pas tous les tests d'un coup puis
>>> ensuite le code de l'appli. On écrit un test, puis le code, puis un

>>> autre
>>> test, puis le code.
>>> Donc au bout d'une heure par exemple, tu n'as pas que des tests,
>>> tu a bien

>>> écrit du code pour ton appli, qui partira en production. Et tu as

>>> les tests
>>> qui vont avec.

>>> Projet petit ou gros, tu ne repousse par l'écrire de ton appli à

>>> la fin.
>>
>> Je ne suis pas d'accord. Je ne vois pas pourquoi commencer par un

>> test pourrait être un plus. Tout d'abord, cela suppose que tu sais ce
>> que tu dois tester, donc tu as déjà défini les spécifications de ta
>> méthode. Le fait d'avoir écrit le test d'abord fige cette méthode, et

>> te pousse à ne pas la modifier par la suite (sinon, tu risques
>> d'avoir des dizaines de tests à modifier). Ce n'est pas comme cela

>> que l'on code dans la pratique. Quand je code, et je pense que c'est

>> la même chose pour la majorité des personnes, j'ai une idée assez

>> précise de là où je vais, mais pas complètement. Je préfère me
>> laisser une certaine latitude de façon à avoir de la place pur de
>> meilleures idées qui pourrait surgir en cours de codage. Va peut
>> paraître étrange, mais je pense que c'est une liberté qui conduit à
>> plus de souplesse et au final, à un mellieur code.
>
> Je ne suis pas d'accord avec le fait qu'on fige la méthode, c'est même

> le contraire. Le cycle de TDD met explicitement en avant le

> refactoring, autre façon d'exprimer le fait d'avoir "une certaine
> latitude de façon à avoir de la place pur de meilleures idées qui
> pourrait surgir en cours de codage". Les tests existants te également

> permettent d'avoir un filet de protection sur tes changements.

Je pense qu'on ne va pas tarder à tourner en rond... On n'est pas
d'accord, je crois que c'est un constat qu'il est facile de faire.

Ca ne signifie pas pour autant que l'un de nous deux est un idiot,
heureusement :)

Perso, je jette le gant, j'ai malheureusement de la comptabilité à
faire, l'équivalent du TDD en gestion :/

[Alexis Krier]

Salut, pareil, j'utilise Mockito. Avant c'était easymock et un jour j'ai vu qqun parler de Mockito sur cette mailing list et j'ai testé. Je le trouve plus simple à la lecture, ce qui aide à la compréhension du test.

Pour rajouter mon grain dans le sujet "to mock or not to mock", j'aime les mocks car ils permettent de vérifier le comportement (boite blanche) de ce que l'on test alors que les TI (ex OpenEJB + HSQLDB) ne le permettent pas ou moins facilement, ca ressemble plus à de la boite noire.
Sur notre projet actuel la majeur partie de la couverture de test est en TI et c'est difficile à maintenir (tests complexes).

Alexis

PS: vive les tests mockés ou non !

Le 18/07/2012 16:12, Denis Sanchez a écrit :

Bonjour à tous

j'ai utilisé mockito et jmock comme framework de mock en environemment java. Et vous vous utilisez quoi?

Quel est pour vous le plus simple d'utilisation et qui répond au mieux à vos besoins.

Merci pour vos retours.

Denis SANCHEZ
Edition - Informatique opérationnelle
VIF
Tél. +33 (0)2 51 89 12 40
Fax +33 (0)2 51 89 12 79
denis....@vif.fr
www.vif.fr

[Jean-Sébastien FRANCK]

Je déterre un vieux sujet car je viens de découvrir une surcouche d'EasyMock qui est vraiment bien faite, ça s'appelle unitils :

• Plus besoin d'instancier soit même l'objet à tester -> @TestedObject
  
• Plus besoin d'utiliser createMock et de galérer pour injecter le mock -> @Mock et @InjectIntoByType
  
• Plus besoin de faire le replay et le verify sur chacun des mocks -> EasyMockUtils.replay() et EasyMockUtils.verify()
  
• ... et plein d'autres fonctionnalités sympas, avec notamment un support du partial mocking

Au niveau du code ça donne quelque chose comme ça :

@RunWith(UnitilsJUnit4TestClassRunner.class)
public class ServiceTest {

    @TestedObject
    private Service service;
  
    @Mock @InjectIntoByType
    private Repository repository;
  
    @Test
    public void testCreate() throws RSPStandardException {
        // ...
      
        expect(repository.persist(...).andReturn(...);
       
        // ...
       
        EasyMockUnitils.replay();
        service.create(...);
        EasyMockUnitils.verify();
    }
}

[ehsavoie]

Perso j'evite les runners dans JUnit tant que je peux et plus encore.

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

2013/3/13 Jean-Sébastien FRANCK <jsebf...@gmail.com>

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.

Visitez ce groupe à l'adresse http://groups.google.com/group/lescastcodeurs?hl=fr .
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Cédric Beust ♔]

2013/3/13 ehsavoie <emmanuel...@gmail.com>

Perso j'evite les runners dans JUnit tant que je peux et plus encore.

Franchis le pas et évite JUnit complètement ;-)

-- 

Cédric

[David Gageot]

Pas joli joli le plug ;-)

Mes préférences vont clairement pour Mockito, sans runner spécial. 

Mockito est plus simple et plus expressif qu'easymock.

David

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/lescastcodeurs?hl=fr .
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

--

David.

[Antonio Goncalves]

Mockito aussi mais n'oubliez pas notre nouvel ami Arquillian... et le NoMock Mouvement biensur ;o) http://www.nomock.org

Antonio

2013/3/13 David Gageot <dga...@gmail.com>

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

[Cédric Beust ♔]

2013/3/13 David Gageot <dga...@gmail.com>

Pas joli joli le plug ;-)

Quel plug ?

-- 

Cédric

[ehsavoie]

@Cedric : bof JUnit fait le job pourquoi devrais je migrer mes tests sur un autre framework ? Le rapport coût sur gain me semblant plus que limité.

Mon seul regret est d'avoir utilisé le springrunner et de ne pas avoir empêché mes contributeurs d'utiliser PowerMock sinon pour le reste cela me convient tout à fait :o)

J'avoue n'avoir regardé la nouvelle génération qu'il y a fort fort longtemps mais je n'ai jamais basculé ;o)

Cheers

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

2013/3/13 Cédric Beust ♔ <ced...@beust.com>

[Emmanuel Lécharny]

Le 3/14/13 8:11 AM, ehsavoie a écrit :

> @Cedric : bof JUnit fait le job pourquoi devrais je migrer mes tests sur un
> autre framework ? Le rapport coût sur gain me semblant plus que limité.
> Mon seul regret est d'avoir utilisé le springrunner et de ne pas avoir
> empêché mes contributeurs d'utiliser PowerMock sinon pour le reste cela me
> convient tout à fait :o)
> J'avoue n'avoir regardé la nouvelle génération qu'il y a fort fort
> longtemps mais je n'ai jamais basculé ;o)

Sans compter que la quasi totalité des développeurs utilisent JUnit, pas
la peine de prendre le risque de les dérouter alors que déjà, pour les
forcer à faire des tests, il faut quasiment les menacer physiquement...

C'est un peut comme un logger : base installée énorme, peut d'envie
d'évoluer, intégration dans tous les IDE du marché, it does the job... etc.

En plus, le projet évolue pour absorber les idées nouvelles (TestNG
était vraiment en avance il y a 4/5 ans, mais JUnit a intégré pas mal de
ses features).

Bref, Junit. What else, Georges ?

[David Gageot]

Manu, on avait dit vendredi pour les trolls.

David.

2013/3/14 Emmanuel Lécharny <elec...@gmail.com>

[Nicolas Labrot]

Le coup du @BeforeClass en static, l'absence de description du scénario de test via annotation, l'absence de datasource, c'est lol quoi! ;D

2013/3/14 David Gageot <dga...@gmail.com>

[ehsavoie]

@Rule pour les datasources ca va bien :)

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

2013/3/14 Nicolas Labrot <nit...@gmail.com>

[Emmanuel Lécharny]

Le 3/14/13 9:44 AM, David Gageot a écrit :

> Manu, on avait dit vendredi pour les trolls.

Bah, c'est pas un troll. A l'époque, quand c'est sorti (2004 ?), j'avais
vraiment trouvé que TestNG apportait des idées intéressantes, mais les
projets sur lesquels j'intervenais utilisaient tous JUnit, et comme
j'arrivais sur les projets quand ils commençaient à merder grave,
c'était trop tard pour migrer sur TestNG.

En plus, quand tu évoquais le sujet, on t'expliquait gentiment qu'il y
avait d'autres chats à fouetter que de migrer vers un nouveau outil de
test, que les grouillots sur-payés qui écrivaient les tests n'allaient
pas en plus être formés sur un nouvel outil, etc, etc. Bref, dommage.

Et puis, petit à petit, junit a comblé ses manques les plus évidents...

Dommage, mais c'est la vie !

[Frédéric Bouquet]

C'est sympa de remonter de thread des oubliettes... L'équipe dans
laquelle je bosse est justement sur ce type de considérations. Le
contexte : on développe un moteur d'exécution où pour exécuter les
tests, ça prend une bonne trentaine de minutes parce que l'on a que
des tests d'intégration. Les tests sont pour beaucoup illisibles et
s'apparente souvent à des hack "haut niveau" pour tester des choses à
potentiellement très bas niveau (comment je peux provoquer
l'expiration d'un timer... Un sleep voyons ! :)).
Donc depuis quelques temps, nous avons un mouvement en interne de
quelques militants qui poussent pour que l'on fasse du test unitaire.
Dans ce cadre, j'ai mis en place du mokito. Après, pour les tests eux
mêmes, j'ai déjà du mal à pousser les assertThat de JUnit 4, alors je
n'ose même pas imaginer avoir recours à un autre framework...

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

[Nicolas Labrot]

[TestNG fanboy] ca remplit la fonction comme un tournevis pourri le ferait pour monter une armoire ikea Pax ;)

2013/3/14 ehsavoie <emmanuel...@gmail.com>

[Thibaud Vibes]

+1 pour les datasource (annotation @DataProvider)

En fait avec JUnit on fait du test unitaires. Point barre. Avec TestNG on peut faire un peu plus.
Nous par exemple on l'a utilisé pour évaluer des classifier: Grâce aux annotations on peut jouer X fois le même test avec des données provenant d'un fichier (qui contiennent la donnée à classer et la classe attendue) et on compare à chaque fois le résultat.

Le nombre de test en succès nous donne la performance du classifier.
J'ai trouvé que c'était beaucoup plus simple à mettre en oeuvre qu'avec JUnit.

Autre truc sympa pour TestNG: la doc.
On peut dire que Cédric s'est (un peu) fait chier pour documenter le framework

Cela dit je suis d'accord avec la majorité, cela ne suffit pas. Aujourd'hui nous sommes toujours sur JUnit et ma tentative "à l'exterieur" n'a pas convaincu le reste de l'équipe (pourtant on est pas beaucoup)