Julien Smadja est consultant chez Xebia où il intervient notamment sur des problématiques liées à la testabilité et la qualité des projets. Intéressé par l'intégration continue, il participe à l'évangélisation de produits comme Jenkins et Sonar.
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.
Pour faire simple, imaginez que sur un seul écran vous puissiez voir en un clin d’œil l’état de vos builds (succès/instabilité/échec), le nombre de tests unitaires et d’intégration agrémenté de métriques telles le nombre de lignes de code, la couverture de code et le respect des normes de codages.
Mieux qu’un long discours, nous vous proposons une courte vidéo de 3 minutes qui démontre la facilité avec laquelle vous pouvez démarrer facilement avec l’outil.
Si vous désirez en savoir plus sur le développement de ce projet, nous vous proposons une rétrospective de ces derniers mois, en partant de la genèse du projet jusqu’à son état actuel.
Les tests d’intégration impliquent souvent plusieurs composants d’une architecture technique (webservices, serveurs de mail, …). Si une action s’exécute sur un composant A qui fait appel à un composant B et si la condition à vérifier dépend de la bonne exécution de B, vous êtes dans un cas d’asynchronisme. La première idée qui vient à l’esprit est d’utiliser un timer, de mettre en pause l’exécution du test pour laisser le temps à l’action de se réaliser. On comprend très vite qu’une optimisation est à portée de main, et si au lieu d’attendre un temps constant on pouvait gagner du temps si l’action s’est réalisée plus rapidement que prévu.
Nous verrons dans cet article qu’il est possible de développer des tests automatisés capables de s’adapter facilement aux contraintes d’asynchronismes et de se passer d’un blocage à temps constant grâce à l’API Awaitility.
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.
Complet
Twitter
