[DOJO ENSIMAG] 69e session du Coding Dojo 19/03/2013 salle H.104
91 views
Skip to first unread message
Jonathan Bonzy
Mar 18, 2013, 5:11:48 AM3/18/13
to cara...@googlegroups.com, ClubAgile...@yahoogroupes.fr
La prochaine session du Coding Dojo se tiendra le mardi 19/03/2013 de 12h00 à 14h00 dans la salle H104 à l’ENSIMAG sur le campus universitaire de Saint Martin d’Hères.
Sujet : Stratégies d'écriture de tests unitaires
L'objectif est d'essayer différentes stratégies d'écriture de tests unitaires pour le code proposé : mock ou pas mock, tester uniquement des méthodes publiques ou plus... Le but n'est pas de définir la meilleur stratégie mais plutôt de confronter différentes pratiques pour écrire des tests unitaires afin de confronter les avantages et inconvénients de chacune.
Déroulement
Nous ferons plusieurs groupes avec des stratégies différentes et nous partagerons ensuite sur les différentes pratiques. Nous essayerons de faire 2 itérations de 45 minutes : 30 minutes de codage + 15 minutes d'échanges.
Venez avec votre environnement contenant le code disponible sous Dojo69-Filtering (implantation en java). Les informations se trouve sur la page d'accueil du repository.
Inscription : sur le site web du CARA
Rémy Sanlaville
Mar 22, 2013, 5:04:08 PM3/22/13
to cara...@googlegroups.com
Bonjour,
Voilà un retour sur la 69e session qui s'est déroulé mardi dernier.
Bien que nous n'étions pas nombreux (3 où nous avons pu accueillir Victor qui venait pour la première fois), la séance a été assez intéressante de par le fait que nous avons essayé plusieurs stratégies. Par contre, nous n'avons pas pu profiter de visions diverses (peut-être que cela pourra être le cas dans une autre session).
Sous le repository Dojo69-Filtering vous retrouverez différents tests (cf. les différentes branches avec leur README associé) :
- ApprovalTests : c'est une librairie que j'ai découvert récemment en préparant notre atelier Développeurs Anonymes avec Johan. J'aurai sans doute l'occasion de vous en reparler. C'est un test orienté test d'intégration qui permet par exemple d'écrire rapidement un test sur un code legacy pour pouvoir le refactorer. L'intérêt de ApprovalTests est de nous simplifier l'écriture de tels tests en peu de temps. Je l'ai écrit avant la session donc nous en avons discuté rapidement car l'objectif de la session était plus orienté test unitaire ;
- FilteringTest-ArgumentsMockito : Nous avons écrit un test unitaire pour la classe Filtering sans mocker la librairie externe Maven Filtering. Nous avons utilisé mockito pour mocker la classe Arguments du projet qui est en entrée de la méthode filter(Arguments arguments). J'ai (je l'ai fait après la séance avant de pousser la branche sur github) utilisé cette fois la librairie FEST-Assert 2.x afin de pallier aux limitations de Approval Tests. Cf le README de la branche pour plus d'explications. Cela fonctionne plutôt bien mais nous trouvons que l'utilisation de mockito ne facilite pas la lecture du test unitaire et que cela pouvait être amélioré (ce que nous avons essayé dans la branche FilteringTest-DIP).
- FilteringTest-DIP : Afin d'améliorer la lecture du test unitaire de la classe Filtering (cf branche FilteringTest-ArgumentsMockito) nous avons commencé par refactorer le test en l'écrivant de façon plus "naturel/lisible". Après discussion, nous nous sommes rendu compte qu'un problème est que la méthode Filtering ne respecte pas le principe DIP (Dependency Inversion Principle, que je vous conseille de lire/relire). Nous avons donc modifié le code source et le test en introduisant une interface IArguments et en fournissant une implantation simplifiée (ArgumentsMock) pour le test. Nous avons été assez content de se refactoring qui a amélioré le code de notre point de vue.
Le DIP améliore la réutilisation d'une méthode/classe. Bastien a fait une remarque judicieuse : ce principe s'applique bien aux tests car nous pouvons dire qu'un test unitaire est une des premières réutilisation d'une méthode/classe. Nous pouvons voir ici un lien directe avec le fait que le TDD améliore la conception d'une application. Je vous laisse lire la section Discussions ;
Nous ensuite essayé de ré-écrire le test unitaire pour la classe Filtering mais cette fois en mockant la librairie externe Maven Filtering (Filtering utilise la classe org.codehaus.plexus.util.FileUtil). En voulant écrire les parties mockito nous avons vite vu les difficultés du fait que la méthode filter de la classe Filtering utilise une méthode statique de la librairie externe (FileUtils.copyFile(from, to, "UTF-8", wrappers)) et instancie les paramètres from, to et wrappers pour cette méthode statique. Cela demande d'utiliser PowerMockito ou des ArgumentCaptor de Mockito. Par expérience, cela n'est ni simple, ni très lisible et pose des problèmes de performances (si on utilise PowerMockito). Comme nous n'avions plus beaucoup de temps, nous souhaitions plutôt chercher une autre solution (j'essayerai néanmoins, si je trouve du temps, de rajouter des branches pour montrer ce que cela peut donner). Nous avons réfléchi pour utiliser de nouveau le DIP. Cela devient plus complexe car nous ne maîtrisons pas le code de la librairie externe pour modifier la signature de la méthode afin de rajouter des interfaces. C'est là que nous pouvons voir l'intérêt de la contrainte d'utiliser une librairie qui ne nous appartient pas. Nous avons vite pu voir que si nous devons intégrer une librairie qui n'est pas forcément bien conçu (ou au moins qui ne facilite pas l'écriture des tests) cela gangrène vite notre propre code. Nous n'avons pas eu le temps de terminer un premier draft, c'est pour cela que je n'ai pas ajouté de branche sur le repository pour cette partie. Néanmoins les discussions étaient très intéressantes et nous sommes sorties avec l'envie de continuer cette expérience. Il nous paraît intéressant de trouver une solution élégante à ce problème auquel nous sommes confrontés quotidiennement.
Note (pour ne pas oublier) : j'aimerai aussi rajouter un test unitaire avec l'utilisation de la librairie Zohhak dont je vous ai déjà parlé une fois afin de fournir un exemple avec cette librairie.
Merci à Victor qui a dû suivre au mieux le rythme de nos discussions et à Bastien pour ses idées et remarques qui nous poussent toujours à progresser.
Perspectives
Je vous propose cela :
- Vous pouvez faire des tests chez vous et me pousser vos branches (essayer de faire un README qui explique ce que vous faites et pourquoi) ;
- Nous continuons l'expérience lors d'une prochaine session. De mon côté, je suis partant car j'aimerai pouvoir trouver une solution élégante à notre dernier problème. Votre point de vue m'intéresse.
Rémy
Voilà un retour sur la 69e session qui s'est déroulé mardi dernier.
Bien que nous n'étions pas nombreux (3 où nous avons pu accueillir Victor qui venait pour la première fois), la séance a été assez intéressante de par le fait que nous avons essayé plusieurs stratégies. Par contre, nous n'avons pas pu profiter de visions diverses (peut-être que cela pourra être le cas dans une autre session).
Sous le repository Dojo69-Filtering vous retrouverez différents tests (cf. les différentes branches avec leur README associé) :
- ApprovalTests : c'est une librairie que j'ai découvert récemment en préparant notre atelier Développeurs Anonymes avec Johan. J'aurai sans doute l'occasion de vous en reparler. C'est un test orienté test d'intégration qui permet par exemple d'écrire rapidement un test sur un code legacy pour pouvoir le refactorer. L'intérêt de ApprovalTests est de nous simplifier l'écriture de tels tests en peu de temps. Je l'ai écrit avant la session donc nous en avons discuté rapidement car l'objectif de la session était plus orienté test unitaire ;
- FilteringTest-ArgumentsMockito : Nous avons écrit un test unitaire pour la classe Filtering sans mocker la librairie externe Maven Filtering. Nous avons utilisé mockito pour mocker la classe Arguments du projet qui est en entrée de la méthode filter(Arguments arguments). J'ai (je l'ai fait après la séance avant de pousser la branche sur github) utilisé cette fois la librairie FEST-Assert 2.x afin de pallier aux limitations de Approval Tests. Cf le README de la branche pour plus d'explications. Cela fonctionne plutôt bien mais nous trouvons que l'utilisation de mockito ne facilite pas la lecture du test unitaire et que cela pouvait être amélioré (ce que nous avons essayé dans la branche FilteringTest-DIP).
- FilteringTest-DIP : Afin d'améliorer la lecture du test unitaire de la classe Filtering (cf branche FilteringTest-ArgumentsMockito) nous avons commencé par refactorer le test en l'écrivant de façon plus "naturel/lisible". Après discussion, nous nous sommes rendu compte qu'un problème est que la méthode Filtering ne respecte pas le principe DIP (Dependency Inversion Principle, que je vous conseille de lire/relire). Nous avons donc modifié le code source et le test en introduisant une interface IArguments et en fournissant une implantation simplifiée (ArgumentsMock) pour le test. Nous avons été assez content de se refactoring qui a amélioré le code de notre point de vue.
Le DIP améliore la réutilisation d'une méthode/classe. Bastien a fait une remarque judicieuse : ce principe s'applique bien aux tests car nous pouvons dire qu'un test unitaire est une des premières réutilisation d'une méthode/classe. Nous pouvons voir ici un lien directe avec le fait que le TDD améliore la conception d'une application. Je vous laisse lire la section Discussions ;
Nous ensuite essayé de ré-écrire le test unitaire pour la classe Filtering mais cette fois en mockant la librairie externe Maven Filtering (Filtering utilise la classe org.codehaus.plexus.util.FileUtil). En voulant écrire les parties mockito nous avons vite vu les difficultés du fait que la méthode filter de la classe Filtering utilise une méthode statique de la librairie externe (FileUtils.copyFile(from, to, "UTF-8", wrappers)) et instancie les paramètres from, to et wrappers pour cette méthode statique. Cela demande d'utiliser PowerMockito ou des ArgumentCaptor de Mockito. Par expérience, cela n'est ni simple, ni très lisible et pose des problèmes de performances (si on utilise PowerMockito). Comme nous n'avions plus beaucoup de temps, nous souhaitions plutôt chercher une autre solution (j'essayerai néanmoins, si je trouve du temps, de rajouter des branches pour montrer ce que cela peut donner). Nous avons réfléchi pour utiliser de nouveau le DIP. Cela devient plus complexe car nous ne maîtrisons pas le code de la librairie externe pour modifier la signature de la méthode afin de rajouter des interfaces. C'est là que nous pouvons voir l'intérêt de la contrainte d'utiliser une librairie qui ne nous appartient pas. Nous avons vite pu voir que si nous devons intégrer une librairie qui n'est pas forcément bien conçu (ou au moins qui ne facilite pas l'écriture des tests) cela gangrène vite notre propre code. Nous n'avons pas eu le temps de terminer un premier draft, c'est pour cela que je n'ai pas ajouté de branche sur le repository pour cette partie. Néanmoins les discussions étaient très intéressantes et nous sommes sorties avec l'envie de continuer cette expérience. Il nous paraît intéressant de trouver une solution élégante à ce problème auquel nous sommes confrontés quotidiennement.
Note (pour ne pas oublier) : j'aimerai aussi rajouter un test unitaire avec l'utilisation de la librairie Zohhak dont je vous ai déjà parlé une fois afin de fournir un exemple avec cette librairie.
Merci à Victor qui a dû suivre au mieux le rythme de nos discussions et à Bastien pour ses idées et remarques qui nous poussent toujours à progresser.
Perspectives
Je vous propose cela :
- Vous pouvez faire des tests chez vous et me pousser vos branches (essayer de faire un README qui explique ce que vous faites et pourquoi) ;
- Nous continuons l'expérience lors d'une prochaine session. De mon côté, je suis partant car j'aimerai pouvoir trouver une solution élégante à notre dernier problème. Votre point de vue m'intéresse.
Rémy
2013/3/18 Jonathan Bonzy <jonatha...@gmail.com>
Rémy Sanlaville
Apr 6, 2013, 6:20:49 PM4/6/13
to cara...@googlegroups.com
Bonjour,
Comme indiqué dans le résumé de la 69e session, je viens de pousser ma branche pour illustrer l'utilisation de la librairie Zohhak.Je vous laisse lire le code sur mon repo et les commentaires que j'ai mis dans le README.
Reply all
Reply to author
Forward
0 new messages