Re: Mockito test

Laurent Forêt <[email protected]> Fri, 4 Feb 2011 11:24:30 +0100
Newsgroups gmane.comp.java.french.general
Message-ID <[email protected]>
 Merci Jérôme pour ta sollicitude , je me sens moins seul sur ce coup là :).

En fait le bug est assez facile à reproduire c'est un service/EJB/Component
A coder dans un module éponyme A
qui passe un mauvais paramètre au service B coder dans un module éponyme
B. Le bug est dans A mais est détecté dans B.

La question que je me pose donc est comment valider la correction de A sans
avoir à faire un test d'intégration de B.
Je pensais à première vue couper la poire en deux injecter mon service B
dans A et mocker toutes les injections des services dont dépendaient B mais
c'est fastidieux pénible et complètement hors de propos dans le cadre d'un
test du module A. D'ou une idée de mocker jusqu'au moment ou je suis  sur
que le bout de code de B qui plantait soit passé, mais ça, ça implique une
bonne connaissance du code de B qui peut à tout moment changer.

Après il y a une autre solution qui consiste à valider tout simplement comme
B le paramètre généré par A . Mais cela implique tout d'abord un refactoring
de A pour pouvoir intercepter le paramètre incriminé (solution chirurgicale
qui me parait pas opportune). Mais aussi, il faut recoder dans le test de A
la validation de ce même paramètre (duplication de code) ou encore utiliser
directement le code de validation du paramètre dans B (mais la ca redevient
un test d'intégration de B).

J'ai pas de solutions corrects dans ce cas et je me pose encore des
questions sur l'usage des mocks. En fait, plus j'en fais plus je m'en pose.


A défaut d'avoir été clair :) , j'ai au moins posé mon problème afin d'y
réfléchir à haute voix. Et comme c'est vendredi c'est permis.

Laurent.

2011/2/3 jerome moliere <[email protected]>

>
>
> Le 2 février 2011 11:44, Laurent Forêt <[email protected]> a écrit :
>
>>  Re salut la liste,
>>
>>  Tiens une petite question sur mockito et plutôt sur son usage, pour
>> changer d'Eclipse ;).
>>
>> Voilà, j'ai un bug que je dois corriger dans du code que je n'ai pas ecrit
>> et dont les tests ne sont pas très unitaires mais plutôt d'intégrations.
>> J'ai deux solutions qui s'offrent à moi :
>>
>>    - configurer mon environnement pour faire en sorte que l'ensemble des
>> tests d'intégrations fonctionnent sur mon poste, rajouter le code qui permet
>> de tester la fonctionnalité buggée, corriger le problème et valider la
>> correction avec le test.
>>
>>>
>>>
>>> Laurent Forêt
>>> http://www.devcoop.fr,
>>> http://laurentforet.org
>>> IvyBeans Creator
>>> Membre du JUG Bordeaux
>>>
>>
>>
>>   - isoler mon problème, ecrire le test en utilisant mockito pour mocker
>> tout ce que je ne veux pas tester, puis coder la correction.
>>
>> Or dans les deux cas la correction tient sur une ligne de code et le test
>> à écrire validant la correction prend une centaine de ligne de code , l'un
>> pour "mocker" tous les beans injecté l'autre pour initialiser tous ces
>> beans.
>>
>>   Je me demandais alors si c'était acceptable de "mocker" jusqu'au bon
>> déroulement de la correction et de catcher le NPE résultant du non "mockage"
>> une fois le code testé passé. Perso, je ne pense pas, mais avez vous des
>> avis ?
>>
>>
> Salut,
> je ne suis pas sûr d'avoir bien compris ton contexte mais si ton souci est
> lié à de l'intégration alors il ne faut surtout pas passer à du mock ...SI
> tu veux faire les choses 'bien' alors reproduis le bug et fixes le tel quel
> et fais en sorte de livrer aussi du test unitaire (donc avec du mock)..
> cela ne va pas arranger ton planning mais ceux qui passeront derrière
> seront heureux je pense....
>
> Jerome
> --
> J.MOLIERE - Mentor/J
> auteur Eyrolles
>
>
>