Tag :Mockito

Retour sur La Marmite – Soirée Crumble

Mardi 7 juin dernier a eu lieu la première édition de notre nouvel événement récurrent :

La Marmite !

Au programme un Hands-On Mockito animé par Mathilde Lemée et David Gageot et en parallèle, un Open Space Technology animé par le reste de l’équipe Duchess France. Pour ceux qui ne connaissent pas le principe des Open Space Techonologies, je vous invite à relire l’article d’annonce d’Ellène Dijoux qui vous éclaircira sur le sujet ;)

IMG_0042IMG_0021

Lors de l’OST, une dizaine de sujets ont été présentés au total et 4 débattus. Les voici dans l’ordre :

1. les test d’IHM : quand ? comment ? pourquoi ? avec quoi ?

Problématique rencontrée par plusieurs participants dans l’assistance : les tests d’IHM. Pas toujours aisés à implémenter, notamment lorsqu’il s’agit de les réaliser avec Selenium : les dépendances que l’on peut avoir avec la base de données par exemple les rendent parfois lourds à maintenir. Ils ne sont pourtant pas là que pour vérifier le comportement de l’application, ils permettent en amont de “blinder” le développement, comme dans toutes couches de l’application. En Wicket par exemple, les tests d’IHM permettent de s’assurer que l’on n’a pas oublié de déclarer un composant en route et en GWT de structurer le développement, ce qui peut s’avérer utile lorsque l’on essaye d’appliquer le très riche MVP à la lettre :D Au final les solutions expérimentées par les participants étaient Mockito pour du GWT et WicketTester associé à un framework de mock (EasyMock ou Mockito par exemple) pour Wicket.

2. ForPlay : présentation de la nouvelle librairie proposée par Google pour développer des jeux cross platform.

Présentée au dernier Google IO, cette librairie a pour but de permettre aux développeurs Java de développer rapidement des jeux comme ceux présentés dans la page DemoLinks. Pierre-Yves Ricau nous a fait un retour d’expérience du développement de 2H4U : un retour plutôt positif ! Le débat a ensuite dévié sur un sujet non moins intéressant : serons nous amenés dans un avenir proche à développer des applications cross platform en entreprise ? En effet entre les tablettes et les smartphones, il n’est plus vraiment nécessaire pour un commercial d’emmener son ordinateur en réunion extérieure s’il peut retrouver toute l’information dont il a besoin à portée de main … Et de la même manière, un employé chargé de collecter des informations sur support papier (si, si, ça existe encore, on vous le promet) pourrait très bien faire le même traitement sur tablette. Un sujet à creuser pour une prochaine fois peut être ;o)

3. Mockito vs PowerMock vs EasyMock : lesquels avez vous utilisés ? lequel avez vous préféré et pourquoi ?

Avant toute chose, petite redéfinition de deux concepts de bases : Mock et Stub. Pour rappel un stub c’est un test fait sur l’état des objets, alors qu’un mock teste le comportement. Grand gagnant du débat : Mockito, qui sans surprise rencontre la préférence de tout le monde ! EasyMock est plus verbeux, plus lourd et parfois limité. Mais il est souligné que la dernière version contient des améliorations. PowerMock ne fait pas l’objet d’une grande argumentation car très peu utilisé, il est néanmoins rappelé qu’il peut être utile à l’occasion pour tester des méthodes statiques ou finales.
Le débat dévie ensuite sur l’intérêt d’écrire des tests unitaires. En effet, il est inutile d’écrire des tests pour écrire des tests ou réécrire la méthode dans le test. Il arrive que du refactoring de code entraîne la modification des tests unitaires alors que le comportement de l’application n’a pas changé. Tout le monde est d’accord sur l’efficacité du test unitaire dans le cas du débuggage. Il permet de gagner du temps en isolant le problème et en permettant de le tester unitairement (sans avoir à packager, redéployer et cliquer dans l’application).
La conversation part ensuite sur git bisect qui permet de retrouver à quel moment on a introduit un bug dans notre code. La stratégie consiste à créer un test qui met en évidence le bug. Puis d’éxécuter le test sur toutes les précédentes révisions par dichotomie. On remonte ainsi vers le commit ayant introduit le bug. Et on peut plus facilement corriger le bug car on connait le bug d’origine.

4. DDD vs BDD vs TDD : dans le cadre d’un nouveau projet, que choisir et pourquoi ?

Le postulat de départ était donc : dans un développement from Scratch, qu’est ce que je choisis ? TDD oui mais comment et pourquoi ? Parce que c’est in ? BDD oui mais … qu’est ce que c’est au juste ? Donc pourquoi ne pas en rester à DDD finalement ? Après avoir défendu les avantages indéniables du TDD (meilleur découpage du code, meilleure définition des contrats, test rapide sur diverses couches “fragiles” : mapping ou requêtage sql par exemple) et être revenu sur la façon dont chacun l’applique dans ses développements, un constat s’impose : le TDD oui, mais à condition que le modèle soit déjà clairement défini ! On passe ensuite à BDD mais avant un petit tour par le blog de duchessfr et l’interview de Mauro Talevi par Agnes Crepet histoire de se rafraîchir la mémoire ;o) Malheureusement personne parmi nous n’a eu l’occasion de le mettre en pratique, néanmoins, dans le cas qui nous intéresse, le modèle n’étant pas encore clairement défini, il se pourrait que ce soit la solution à retenir. Car si le modèle n’est pas prêt, il est probable que le développement commence par les services et dans ce cas, le BDD pourrait s’avérer particulièrement utile. Quant au DDD … ah bah tiens, personne n’a pris la peine de le défendre celui ci :D

La conclusion

Certains parmi nous testaient l’OST pour la première fois et le résultat est plus que positif : l’échange est riche, on recueille quelques conseils au passage, bref un format qui a tout bon ! Et le plus drôle c’est que si l’on arrive avec la peur de n’avoir pas de sujet à proposer, les idées fusent pendant les débats et l’on termine la soirée avec plein d’idées pour la prochaine fois ;) Et comme il est important de ne pas perdre les bonnes habitudes, nous avons bien sûr fini la soirée en beauté avec une troisième mi temps :D

Les vacances approchent, mais nous espérons vous retrouver nombreux à la rentrée pour de nouvelles sessions de La Marmite ! Et si certains ou certaines parmi vous souhaitent animer un hands-on, n’hésitez pas à nous contacter à l’adresse habituelle : duchessfr(at)gmail(dot)com.

La Marmite : Soirée Crumble pour la première édition !

Nous vous en avons parlé lors de la soirée Anniversaire et la voici qui s’annonce : La Marmite, le rendez vous régulier organisé par Duchess France débute le mois prochain !

La Marmite ? Qu’est ce que c’est ?

logo-marmite

La Marmite est un rendez vous récurrent que nous souhaitons mettre en place pour échanger sur les meilleurs outils et recettes de développement ;)

Elle est ouverte à tous, quelque soit votre niveau mais attention, il ne s’agit pas d’une soirée avec présentation par un speaker, c’est une soirée où l’on va partager (des astuces de fabrications et des bonnes pratiques) voir mettre les mains à la pâte pour ceux qui sont prêts à se salir :D

La soirée Crumble

En clin d’oeil à une des questions posées lors de la soirée Anniversaire, nous avons baptisé la première édition la soirée Crumble. Au programme de la soirée, nous vous proposons 2 tracks en parallèle :

1- Hands-On Mockito avec Mathilde Lémée et Brice Dutheil, commiter Mockitologo

Niveau requis : De débutant à intermédiaire

Durée : 2h

Venez découvrir Mockito en pratique.

Qu’est-ce que Mockito ?

Mockito est un framework qui permet de réaliser des mocks. Très utilisé dans l’écriture de tests unitaires, vous allez pouvoir le mettre en place sur du code legacy. Vous découvrirez ainsi les enjeux d’un tel framework pour vos projets.

Que vous faut-il pour cette soirée ?

Tout d’abord il vous faut un ordinateur avec au minimum sur votre poste : Java bien évidemment :) , Maven, et un compagnon de travail que vous pourrez trouver sur place car le projet se fait en pair programming.

Qu’est ce que le pair programming ?Duchess Coding Dojo - TDD with FitNesse

Le pair programming ou programmation en binôme, est une méthode de travail où 2 développeurs travaillent ensemble sur une même partie de code. Dans cet exercice, chacun a son rôle :

  • Le pilote : qui a le clavier et se charge d’écrire,
  • Le co-pilote : qui va aider et détecter les éventuels problèmes.

2- Partager vos idées et expérience lors de notre Open Space

Niveau requis : Pour tous !

Durée : 2h

Vous avez rencontré un problème sur votre projet ? Vous aimeriez le partager, comparer votre point de vue avec d’autres personnes ? Participez donc à notre Open Space Technology et venez avec vos sujets techniques, organisationnels ou autres ! Nous débattrons ensemble du sujet. L’essentiel est de partager ! C’est vous qui décidez du contenu.

Qu’est ce qu’un Open Space ?

L’open space est une méthodologie permettant de structurer des conférences. Dans un premier temps, des volontaires annoncent des sujets qu’ils aimeraient aborder. Les gens votent puis les sujets les plus populaires seront traités par 4 en parallèle sur 20 minutes. Chaque session se conclue par une phase de restitution où le porteur de chaque sujet fait le bilan des échanges. Nous proposerons 4 sessions de 30 minutes (20 minutes d’échanges et 10 minutes de restitution).

Alors venez nombreuses et nombreux !

Quelques infos pratiques sur la soirée :

  • Où ? Dans les locaux de SupInfo – 23 rue du Château Landon, 75010 Paris
  • Quand ? Le 7 Juin 2011
  • Comment s’inscrire ? En réservant votre place sur Event Brite

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer