Tag :Tests Unitaires

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.

Interview de Mauro Talevi, speaker MIX-IT sur Behavior Driven Development (BDD) et JBehave

logo_mixitUne nouvelle rencontre avec un des speakers de MIX-IT. Vous avez déjà pu lire sur le blog des JDuchess l’interview des speakers Christophe Grand et Laurent Petit sur Clojure, ou encore celle de Nicolas Martignole, keynote speaker de la conférence. Aujourd’hui, c’est au tour de Mauro Talevi qui nous fait également l’honneur d’être présent parmi les speakers de MIX-IT. Et quel honneur! Mauro est un des principaux contributeurs au développement de JBehave, un framework Java permettant de faire du Behavior Driven Development (BDD) dont nous allons découvrir les concepts lors de cet interview.

Mauro Talevi travaille pour la société Agilesque, à Londres, spécialisée dans le conseil, le coaching et les développements Agile. Il a accompagné les entreprises dans la réalisation de gros projets en introduisant les pratiques et les outils Agiles, convaincu que les meilleurs résultats peuvent être obtenus en réunissant les bonnes idées et les outils appropriés pour les implémenter. Il est actif dans de nombreux projets open-source, notamment JBehave.

Mauro talevi, Tech Lead of JBehave

Mauro Talevi

Agnès: Comment et quand a émergé l’approche du Behavior Driven Development (BDD), quels étaient les objectifs initiaux de cette méthode? Comment la situer vis-à-vis du Test Driven Development (TDD), du Domain Driven Design (DDD), et des tests d’acceptance *1 automatisés?

Mauro: Le terme de BDD a été inventé par Dan North lorsqu’il essayait d’améliorer la manière d’introduire TDD à des équipes qui découvraient les pratiques agiles. L’expérience de Dan en tant que coach agile a mis en exergue les aspects de TDD qui n’étaient pas facile à appréhender pour des néophytes et qui pouvaient ébranler les bénéfices de TDD pour les utilisateurs expérimentés. Ces aspects concernaient notamment la définition du scope de chaque test, le fait de déterminer quelle convention de nommage devrait être utilisée et quelle information devrait être remontée lors de l’échec d’un test. BDD – en substance, le fait que décrire le comportement attendu soit un meilleur moyen de tester – a été la réponse de Dan à ces écueils perçus de TDD. Dans cette optique, vous pouvez parfois entendre que «BDD est TDD bien fait», mais BDD, au fil du temps, a évolué pour devenir un paradigme à part entière du développement qui complète TDD plutôt que d’essayer de le remplacer.
L’objectif initial fixé sur le langage et la communication – qui a toujours été l’une des principales caractéristiques de la philosophie sous-jacente à BDD – a évolué pour englober plus largement l’ensemble de l’Analyse Agile. Décrire le comportement attendu (mais pas encore implémenté) devient alors l’objectif principal de la phase d’analyse. Comme en DDD, l’accent est mis sur le développement d’un langage universel (voir question suivante). De plus, le comportement analysé, décrit sous forme textuelle, constitue le critère d’acceptance pouvant être automatisé. En revanche, tous les tests d’acceptance automatisés n’expriment pas le comportement attendu sous une forme compréhensible par les StakeHolders *2.

Agnès: Quels sont les concepts fondamentaux sous-jacents à BDD? Eric Evans dans son livre célèbre “Domain-Driven Design” a décrit l’usage d’un langage universel (ubiquitous language) pour modéliser un système, basé sur un vocabulaire réellement métier. BDD reprend ce concept d’ubiquitous language. Comment BDD permet-il de faire « pénétrer » ce vocabulaire métier dans le code, et notamment dans l’écriture des tests?

Mauro: BDD place en priorité haute le fait d’axer la communication sur le comportement même du système. Pour arriver à cela, il tente de créer un langage universel, c’est-à-dire un langage qui peut être partagé entre les membres de l’équipe et les StakeHolders. Ce langage devrait être un Domain Specific Language (DSL), un langage dont la syntaxe est bien comprise par tous et possède une signification centrée sur le métier.

A travers les échanges entre les products owners et les équipes et sur la base de ce langage commun, des Stories puis des Scenarios vont être définies. Ces deux termes sont utilisés pour décrire le comportement d’une application. Une Story correspond à une définition très haut niveau d’une exigence métier. On parle aussi de User Story en Scrum. On peut même utiliser un template pour décrire la Story :

En tant que
Je veux
De sorte que

Nous allons utiliser l’exemple simple d’une personne voulant acheter une place de concert pour le groupe de rock Arcade Fire. L’une des Story pourrait ressembler à ceci:

Titre: la personne retire sa place à la billetterie du concert
En tant que fan du groupe de rock Arcade Fire,
Je veux retirer ma place de concert sur un site de billetterie en ligne,
De sorte que je n’ai pas à faire la queue le soir du concert et de sorte que je sois sûre d’avoir une place

Plusieurs Scenarios vont pouvoir alors s’appliquer à une Story : le nombre de place restante est suffisant, il ne reste plus de place pour le concert. Ces Scenarios peuvent eux-mêmes être décrits selon un modèle de syntaxe. Ils vont alors être définis en texte simple respectant une forme structurée composée d’Etapes, chacune correspondant elle-même à une phrase commençant par l’un de ces trois mots clés:

Etant donné que
Quand
Alors

En utilisant ce modèle de syntaxe des étapes, voici ce que pourrait être les scenarios de notre Story :

– Scénario 1: Le nombre de places pour le concert est suffisant
Étant donné que le nombre de places pour le concert est suffisant
Et que je dispose de la somme d’argent nécessaire
Lorsque je demande ma place
Alors assurez-vous que le nombre de place restante est décrémentée
Et s’assurer que la place de concert me soit attribuée

– Scénario 2: Le nombre de places pour le concert est insuffisant
Étant donné que le nombre de places pour le concert est insuffisant
Lorsque je demande ma place
Alors le site de billetterie en ligne m’indique que je ne pourrai assister au concert qu’en allant acheter ma place le soir même.

En substance, BDD crée un mapping entre les étapes textuelles (compréhensibles par les humains) et les méthodes exécutables (compréhensibles par les machines). Ce mapping peut également supporter la définition de paramètres qui permet alors la réutilisation de ce mapping, autrement dit un ensemble de modèle d’étapes définissant la syntaxe des étapes autorisées (Etant donné que, Quand, Alors). Il est crucial que cette syntaxe des étapes soit définie de manière cohérente et à un seul endroit. Par exemple, JBehave utilise les annotations java pour associer la syntaxe des étapes aux méthodes exécutables. Cette syntaxe des étapes peut être publiée et utilisée comme blocs de construction par ceux qui écrivent les Stories et les Scenarios définissant le critère d’acceptance.

Agnès: En quoi BDD est un moyen efficace d’améliorer la communication entre les l’équipe de développement et les StakeHolders, et de fait la définition des besoins métiers? Qu’est-ce qui fait de BDD un puissant levier pour déployer l’agilité sur un projet?

Mauro: Comme mentionné précédemment, BDD encourage la définition d’un DSL et d’une syntaxe d’étapes. Une fois que ces éléments ont été définis, les scenarios peuvent être écrits par n’importe quel membre de l’équipe et vérifiés par d’autres membres de l’équipe et par les StakeHolders. Ils peuvent même être écrits par les StakeHolders eux-mêmes, à condition qu’ils aient acquis une compréhension suffisante du langage. BDD permet la définition de tests d’acceptance automatisés, le fameux critère “Done” requis par Scrum et d’autres méthodes agiles (on parle aussi de Definition of Done, DoD, qui détermine si l’implémentation d’un élément de backlog de produit est bien terminée et satisfaisante d’un point de vue métier). Ces tests peuvent être écrits avant que la fonctionnalité soit développée, par conséquent on parle de “behaviour-driven”, piloté par le comportement voulu, à savoir par le métier. BDD devient aussi un paradigme pour l’analyse Agile puisque décrire le comportement conduit ainsi à une compréhension plus approfondie du système. BDD peut impulser ainsi une forte confiance, à la fois aux StakeHolders à qui on donne – itération après itération – une preuve tangible du comportement précis du système, et à l’équipe à qui on fournit des critères d’acceptance à satisfaire en béton.

Agnès: Te concernant, comment et quand t’es tu intéressé à cette approche? L’as-tu déployé sur d’importants projets? Quelles difficultés as-tu pu rencontrer? Quel bilan peux-tu faire des projets ayant déployés les pratiques BDD?

Mauro: Je me suis impliqué dans BDD à la fin de l’année 2006. A cette époque, j’utilisais Fit comme un outil pour les tests d’acceptance automatisés. Il avait des fonctionnalités intéressantes comme la possibilité de créer un DSL (avec pour convention le nom de méthode), mais il devenait de plus en plus limitée par sa nature tabulaire. Lors d’une conférence à Londres, Dan m’a fait connaitre BDD et JBehave et j’ai immédiatement trouvé que cet outil adressait les problèmes auxquels je me heurtais avec Fit. J’ai commencé à utilisé JBehave dans un projet commercial en 2008. Nous avons eu la chance d’avoir ce projet entièrement nouveau à faire croitre en interne, permettant l’introduction des concepts BDD auprès de l’équipe et des StakeHolders. Mais cela ne nous a pas empêché de faire des erreurs et de tomber dans des pièges, notamment sur le fait de savoir comment présenter et comment communiquer de larges ensembles de données. Nous avons attaqué avec de gros fichiers en format XML, ce qui était facile à dupliquer mais très difficile à maintenir et refactorer. Nous avons tiré bénéfice de ces erreurs et avons migré beaucoup de ces données dans des structures tabulaires – plus lisibles au format texte et plus facilement refactorables.
Aujourd’hui, BDD est beaucoup plus largement utilisé. Tous les projets pour lesquels j’ai promu l’adoption de BDD ont jugé que cette méthode était utile, que ces projets utilisent l’approche agile ou non. De manière commune avec l’Agilité, BDD n’évite pas les difficultés au projet, il les rend simplement plus visibles.

Agnès: Tu es l’un des responsables et fondateurs du projet JBehave, aux côtés de Dan North, la première personne a avoir introduit cette notion de BDD . Peux-tu présenter JBehave, les domaines qu’il adresse? Comment et pourquoi vous est venue l’idée de vous lancer dans le développement de ce framework?

Mauro: JBehave a été le premier projet à mettre en œuvre en Java les idées sous-jacentes à BDD. Il s’est concentré sur l’entrée textuelle, considéré comme le Golden Master, exprimant le comportement attendu en utilisant un langage universel automatisable. Les User Stories en entrées sont analysées et ventilées dans des Scénarios et des étapes, qui sont tour à tour mappés aux méthodes Java en utilisant les annotations et aux patterns d’étape. JBehave prend en charge toutes les notions de BDD et est parfaitement piloté par la demande des utilisateurs. Nous nous sommes efforcés d’aborder le développement de telle manière à vraiment livrer la fonctionnalité attendue et le comportement qui était nécessaire et utile pour les utilisateurs. Toute l’équipe voulant tester un système qui peut être accessible via une API en Java peut utiliser et bénéficier de JBehave. Il est à noter que le système sous-jacent aux tests ne doit pas être lui-même forcément écrit en Java.
Par exemple, nous pouvons tester n’importe quelle application Web avec un framework comme Selenium, qui propose (comme d’autres) une API Java, pour piloter l’interaction avec les pages web.

Cette interview a été réalisée en anglais. Voici mes notes de traduction:

*1 : en français on devrait parler de tests d’acceptation, mais permettez-moi cet anglicisme ! L’approche ATDD (Acceptance Test Driven Development) est une approche qui place les tests métiers au cœur du projet : le Product Owner préférera alors spécifier sa demande via ces tests d’acceptance, indiquer comment vérifier que sa fonctionnalité désirée est correctement implémentée, plutôt que de se contenter de la décrire dans un document de spécification. De la même manière j’ai laissé le terme de critère d’acceptance plutôt que de parler de critères d’acceptation.
*2 : Littéralement “partie prenante”, mais je n’ai volontairement pas traduit le mot “StakeHolders”. J’aurais pu peut-être utiliser le terme se rapprochant, emprunté à Scrum, de “Product Owners”. Mais les “Stakeholders” sont souvent plus que les “Product Owners”. Ils représentent toutes les personnes qui ont un intérêt (“Stake”) dans le projet, mais ils ne portent pas nécessairement toute la responsabilité des “Product Owners”.

Merci Mauro! Et rendez-vous le 5 avril à Mix-IT

Les inscriptions à Mix-IT sont ouvertes!

Allez découvrir le programme sur le site pour vous inscrire!
Et d’ici là suivez @mixIT_lyon sur twitter pour avoir plus d’informations!

Soirée David Gageot : les tests unitaires au Paris JUG

Vous voulez prouver à tout le monde que non content d’être là mardi vous avez écouté David  avec toute la discipline de padawan requise et que vous n’étiez pas en train de chercher la fève gagnante parmi les galettes du buffet ?

Alors faites le test et frimez devant vos collègues en réalisant un 100% parfait !

Si mon test dépasse l’heure :

A – Mon build prend trop de temps mais c’est pas grave, vu la rapidité de Maven, personne ne s’en rendra compte
B – C’est trop long, je le supprime et j’arrête les tests
C – Cool, je peux rester à jour de ma timeline Twitter tout en jouant sur Facebook !
D – J’ai toujours un test en train de tourner, c’est parfait car je travaille en NTD (Neverending Test Development)

IMG_6972

Pour résoudre un problème difficile David Gageot :

A – Se maquille outrageusement et met des platform boots
B – Fait beaucoup de bruit
C – Applique le principe KISS (Keep It Simple, Stupid)
D – Viens nous voir

La phase de test sera forcément plus courte :

A – Avec une solution d’intégration continue multi-agent avec Hudson parallélisée sur un cloud
B – Si je change pour un quadri-coeur
C – En utilisant l’option “-T4” de Maven3 dans la commande “mvn clean install”
D – Si chaque test est plus performant
E – Si on enlève ceux qui ne servent à rien

Je peux rendre mes tests plus rapides :

A – En retournant jouer dans mon bac à sable
B – En cassant tous mes gros tests en petits morceaux
C – En me laissant pousser la barbe et en me teignant en roux dans l’espoir de ressembler à David Gageot
D – En délaissant Sélénium pour tester le code de l’IHM au profit d’un vrai test unitaire en Javascript
E – En améliorant mon code

Que sont les tests d’intégration ?

A – Ils servent à accueillir les nouveaux tests
B – Ils permettent de vérifier que l’application fonctionne de bout en bout
C – Ils testent les spécifications du domaine
D – Ils sont nécessaires pour tester l’IHM

A quoi sert le plugin MoreUnit pour Eclipse ?

IMG_7037
A – A dupliquer tous les tests unitaires pour les passer 2 fois au cas où
B – A montrer qu’Eclipse c’est quand même vachement mieux qu’IntelliJ IDEA vu que ça n’existe pas pour d’autres IDE
C – A fournir des tas de fonctionnalités super sympa aux courageux développeurs qui testent envers et contre tout et peuvent alors siffler en testant
D – A lancer le test depuis la classe sous test unitaire

A quoi sert le plugin Infinitest ?

A – A ne jamais terminer chaque test pour faire du NTD (Neverending Test Development)
B – A rejouer les tests impactés de manière transitive par la modification d’une classe
C – A embêter les gens qui utilisent TestNG pour qu’il reviennent à JUnit
D – A visualiser rapidement quel test est mis en échec par les modifications qui viennent d’être apportées dans le code

Qu’est ce que FEST-Assert ?

A – Un truc plus tendance que Hamcrest
B – Un outil qui extrait les règles à vérifier du code pour éliminer la maintenance
C – Une librairie qui permet d’écrire les assertions de manière plus naturelle
D – Un site pour s’assurer qu’il y a toujours un festival dans le coin

Quelles sont les annotations JUnit valides ?

IMG_7030

A – @Rule
B – @AfterTestWhenAllIsFine
C – @Theory
D – @Categories et @SuiteClasses

Les réponses

Les réponses sont dans un post secret protégé par mot de passe, mais comme on sait que vous allez répondre à tout en 5 mn et ne pas pouvoir patienter plus longtemps pour prouver à vos collègues que vous êtes maintenant incollable sur les tests unitaires, le voici : testsrocks ;-)

Les photos sont de José Paumard du Paris JUG.


Protected: Soirée David Gageot : les tests unitaires au Paris JUG – les réponses

This post is password protected. To view it please enter your password below:


Soirée David Gageot – Débutez l’année avec plein de bonnes résolutions

David Gageot

Une nouvelle année débute et nous avons tous en tête de bonnes résolutions, comme augmenter le taux de couverture de code sur notre projet ou compléter la Javadoc. Pour nous aider à appliquer tout ça, David Gageot, auteur du blog Java Bien!, nous propose une soirée entièrement dédiée aux tests.  En exclusivité pour les Duchess, David Gageot nous fait l’honneur de répondre à quelques questions.

@dgageot

Qu’est ce que la soirée David Gageot aura de plus que la soirée Emmanuel Bernard ?

Ce qui me vient en tête en premier, c’est une barbe rousse… A part ça, sans dénigrer le travail d’Emmanuel, je pense qu’à la question “Qui utilise Hibernate ?”, la réponse est évidement, ”Pas grand monde”, alors qu’à la question “Qui a une couverture de tests de 100% ?”, tu imagines bien que la réponse est “Tout le monde”. Ou bien est-ce l’inverse… Ce qui est certain, c’est que l’on va beaucoup parler de tests. Et ça tous les développeurs sur la planète doivent se sentir concernés. (Note aux organisateurs : il va falloir un bon million de chaises pour tous les asseoir) Un doute subsiste : David Gageot était présent à la soirée Emmanuel Bernard. Mais Emmanuel Bernard sera-t-il présent à la soirée David Gageot ?

D’après ce que je vois dans le programme de la soirée tu as l’intention de donner des conseils pour diminuer le temps de build sur les tests. Mais tout le monde sait que tester c’est douter alors pourquoi ne pas simplement supprimer les tests ?

C’est une bonne remarque. Le doute est une bonne arme de destruction massive de tests. Supprimer des tests est d’ailleurs une de mes techniques préférée pour diminuer le temps d’un build. Supprimer les bugs serait encore plus efficace. C’est d’ailleurs ma principale résolution pour 2011. Ecrire du code sans bug.

Que pourrais tu nous conseiller pour convaincre les têtes de mule réfractaires à l’écriture de tests unitaires ? (Personnellement j’ai essayé le fouet mais il n’est pas très efficace …)

La lapidation est parait-il plus efficace que le fouet pour convaincre les irréductibles. Personnellement je ne fréquente plus ces personnes là.

Les fainéants et tricheurs trouveront-ils vraiment leur compte dans ta présentation ?

C’est promis. Dès la slide 14 je m’adresse à eux et à eux uniquement. Les autres devront sortir de la salle jusqu’à la slide 26. (Note aux organisateurs : prévoir une animation musicale dans le couloir pour les faire patienter)

Pour donner le bon exemple, pourrais tu nous donner quelques statistiques sur l’un de tes projets (couverture de code, nombre de tests unitaires, taux de commentaires …) ?

95% de couverture de code. 3648 tests unitaires et fonctionnels. 6873 assertions. 5 lignes de commentaires mais de la javadoc sur l’API publique. 56742 lignes de code et 57131 lignes de test. Un build complet en moins de 4 minutes. Une dizaine de balles de jonglage. Des tonnes de post-its “Super Sticky”. Aucun animal n’a été blessé pendant le développement.

Un petit mot de plus pour inciter les gens à venir à cette soirée David Gageot ?

Si Emmanuel Bernard vient à ma soirée, les gens pourront parler avec lui dans le couloir si la présentation est ennuyeuse. Chose absolument impossible à la soirée Emmanuel Bernard.

Merci David !

Les inscriptions seront ouvertes le jeudi matin !

Vous le savez déjà, les places partent extrêmement vite !! Surveillez vos mails et venez nombreux et nombreuses à cette soirée qui promet d’être très intéressantes pour la qualité de nos développements !

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