Notre quotidien de développeur consiste très souvent à modifier du code existant. Certes, nous avons parfois la chance de développer de nouveaux modules tout frais, tout neufs et le Test Driven Development est à son avantage.
Mais comment peut-on mettre en pratique le TDD sur du code déjà écrit, parfois mal pensé et non testé. Cet article va partir d’un exemple concret, une classe comme on pourrait en trouver sur tous les projets. Le but est de commencer une démarche TDD et de pousser au maximum son efficacité (mise en évidence d’un bug potentiel, ajout d’une nouvelle fonctionnalité, refactoring du code et refactoring des tests). Au final, la classe sera beaucoup plus apte à subir le changement et surtout, elle sera testée et couvrira tous les cas d’utilisation.
Lire la suite de cet article »
La prochaine session du Paris Scala User Group aura lieu mardi 25 Octobre à 19h30 dans les locaux de Xebia.
A cette occasion, Jean Helou nous proposera la résolution d’un mastermind sous forme d’un kata TDD. Le but est de partir d’une version impérative du programme et la refactorer en utilisant les principes de la programmation fonctionnelle.
Il reste encore quelques places, si vous souhaitez y assister, pensez à vous inscrire pour la logistique.
Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage
Le 4 Juin 1996, à 9h35 le vol 501 de la fusée Ariane 5 effectue son premier décollage. Quelques secondes plus tard, le système de guidage inertiel reçoit trop d’informations et se met hors service, car reconnu défaillant. L’ordinateur de bord est alors notifié qu’un dysfonctionnement est en cours et compromet les informations concernant la trajectoire de la fusée. Cette modification de la trajectoire entraîne l’arrachage d’un moteur d’appoint, déclenchant l’auto destruction de la fusée. Des analyses plus approfondies ont démontré que le système de guidage inertiel est lui même la cause de cet échec. Conçu à l’époque pour Ariane 4, il n’était plus nécessaire pour Ariane 5. Maintenu actif pour des raisons de commodité, ce système s’est avéré être à l’origine d’un des bugs informatiques les plus coûteux de l’histoire.
Au-delà du caractère spectaculaire de cet exemple, il est intéressant de noter que l’origine du dysfonctionnement réside dans un module développé pour une version antérieure de la fusée et devenu obsolète. Ce vestige de code, maintenu dans l’application sans être nécessaire pour son fonctionnement, est l’une des formes de ce que Ward Cunningham désigne sous le terme de dette technique.
A travers ce document, nous découvrirons en quoi la dette technique ralentit la productivité des équipes et nuit aux projets. Nous mettrons en évidence ses mécanismes sous jacents et les leviers d’actions dont nous disposons. Enfin, nous montrerons comment elle se gère au quotidien, par l’instauration de bonnes pratiques de développement et la mise en place d’outils, pour enfin aborder quelques stratégies complémentaires, mais essentielles pour venir à bout de la dette technique.
Télécharger le Livre blanc « Maîtrisez votre dette technique ».
La conférence Software Craftsmanship 2011 – à propos de laquelle deux billets ont déjà été publiés : How Object-Oriented are you feeling today ? et Lean code challenge - s’est clôturée avec la session dite du Cyber dojo, inventé, programmé et présenté par Jon Jagger.
Le Cyber dojo est un exercice d’apprentissage dans lequel les participants peuvent pratiquer l’écriture de logiciel en « entraînement intentionnel » (deliberate software practice).
L’entraînement intentionnel c’est lorsque l’on cherche à améliorer sa capacité à réaliser une tâche. On parle de technique, d’habileté et surtout de répétition. On réalise donc une tâche dans le but d’améliorer la maîtrise d’une ou plusieurs parties de la réalisation de cette tâche. Cela implique un grand nombre de répétitions, jusqu’à ce que l’on atteigne le niveau de maîtrise désiré. On pratique l’entraînement intentionnel dans le but de maîtriser la tâche à accomplir, non dans l’unique but de l’accomplir.
Le Cyber dojo est particulièrement adapté pour travailler la collaboration entre les équipes et le TDD. L’originalité de l’exercice est que l’ensemble des participants soumet son code à un serveur central qui exécute les projets et garde une trace de ces exécutions.
Les participants travaillent en petits groupes. Chaque groupe travaille sur un seul ordinateur :
- en écrivant le code et les tests associés dans un navigateur ;
- en les soumettant au serveur de CyberDojo aussi souvent qu’il le désire. Le serveur exécute alors le projet et retourne le résultat des tests au navigateur.
Le serveur de CyberDojo permet d’exécuter du code dans plusieurs langages : C, C++, C#, Java, Javascript, Objective C, Perl, PHP, Python, Ruby.
Lire la suite de cet article »
En tant que développeur, ne vous êtes vous jamais dit entre deux itérations : « Ah, si seulement j’avais un peu de temps je tenterais d’écrire ce code autrement ? ».
N’attendez plus ! Une code retreat est organisée dans les bureaux de Xebia ce 24 Juin.
L’idée de cette journée est l’amélioration et le partage des compétences au travers d’une pratique répétée de techniques de programmation.
Le principe est le suivant: sur la journée coder en binôme sur plusieurs sessions de 30-45 minutes chacune afin de résoudre un problème. A l’issue de chaque session on change de binôme et tout le code produit est effacé. Drastique mais efficace pour rester créatif. C’est aussi le lieu privilégié pour tester de nouvelles techniques et algorithmes.
Le langage retenu est Java – le code existant du problème étant en Java – et la méthodologie privilégiée le Test Driven Development. Si vous n’êtes que débutant en TDD, cela sera l’occasion d’apprendre aux côtés de gens plus expérimentés.
Rendez-vous le 24 juin à partir de 9h30 jusqu’à 17h dans les bureaux de Xebia au 156 boulevard Haussmann, Paris. Vous aurez besoin d’un ordinateur portable muni de votre IDE préféré. Le repas de midi est fourni.
Le nombre de place est limité à 20; nous vous invitons à vous inscrire sur http://coderetreat-paris.eventbrite.com
Pour plus de détails sur le fonctionnement d’une code retreat vous pouvez parcourir le billet « How a code retreat works ».
Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.
Palais de justice de Paris, lundi 21 mars.
Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.
Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.
Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.
Lire la suite de cet article »
La testabilité est devenue un facteur à prendre en compte lors du choix d’un composant technique. Pour les EJB 3.0, il existait plusieurs manières de tester des services développés, Ejb3unit (figé depuis mi-2009) ou Arquillian (uniquement côté JBoss AS). Les EJB 3.1 offrent enfin une solution native, prête à l’emploi et simple à manipuler : l’EJB Container.
Cet article présente l’utilité de l’EJB Container et la manière de l’utiliser ; il s’appuie pour cela sur l’écriture d’un service et d’une suite de tests exécutables sur Glassfish 3 et sur JBoss 6.
Lire la suite de cet article »
Quand on est en phase de développement et que l’on pratique le TDD, il est nécessaire de connaître certaines méthodes pour éviter la répétition, une fatigue des doigts évidente et ainsi améliorer son rendement.
Nous essayerons dans cet article de montrer l’ergonomie d’Eclipse et l’utilisation du clavier pour rendre plus courte et plus agréable une session TDD. Nous présenterons quelques plugins Eclipse et aussi un outil souvent négligé que sont les templates de codes.
Un pattern sera introduit pour faciliter l’utilisation des objet métiers et POJO dans les tests.
Enfin, nous présenterons le concept important du Continuous Unit Testing appliqué à l’IDE et indiquerons et comparerons les plugins Eclipse pour le mettre en œuvre.
Lire la suite de cet article »
Xebia a le plaisir d’accueillir le deuxième KawaCamp dans ses locaux jeudi 27 Mai 2010.
Qu’est ce qu’un KawaCamp ? C’est un BarCamp dédié aux sujets qui gravitent autour de l’écosystème Java ! Et qu’est-ce qu’un BarCamp alors 
? Pour résumer voici la définition de Wikipedia. Nous allons nous retrouver entre passionnés pour discuter de sujets qui nous tiennent à coeur autour de tables rondes/ateliers durant lesquels chacun participe et donne son point de vue.
Les sujets sont choisis grâce aux centres d’intérêts que chacun exprime sur la page d’inscription. Cette session s’oriente vers les sujets d’actualité avec beaucoup de HTML5 et d’Android sans oublier NoSQL, TDD, Agilité, …
Si vous aimez les discussions passionnées autour d’un verre, le KawaCamp vous comblera en organisant nos débats !
Informations pratiques :
Ils en parlent :
Parmi les tâches incontournables de la vie d’un développeur, il y a l’écriture des tests unitaires. De nombreux outils tentent de nous faciliter la vie sur ce point. Aujourd’hui, je vais vous parler de JTestR, un framework de tests unitaires qui apporte la puissance et la rapidité d’écriture du scripting Ruby pour tester des applications Java. Lancé par Ola Bini, un contributeur incontournable du projet JRuby, JTestR est directement intégrable avec Ant, Buildr et Maven 2. Ce projet n’est pas encore très répandu, mais il apporte des avantages qui méritent d’être étudiés.
Lire la suite de cet article »
Complet
Twitter
