Les DAO (Data Access Object) ou repository des applications contiennent souvent de l’information importante sur la façon dont les données d’une base doivent être consultées. Cette information prend la forme d’une logique métier qui est encodée dans un ou plusieurs langages, souvent un langage déclaratif (SQL, HSQL, JPQL, etc.) et un langage impératif (Java, Groovy, Scala, etc.).
Tester cette logique d’accès polyglotte peut s’avérer complexe et lent car ce type de test se prète mal aux techniques classiques de mock et nécessite plutôt l’écriture de tests d’intégration qui chargent une partie du contexte réel d’exécution. Par conséquent, les tests de cette couche sont parfois délaissés, voire abandonnés.

Cet article se propose de vous montrer comment réaliser de tels tests, avec un niveau d’isolation suffisant pour la parallélisation dans un processus multithread, tout en essayant de trouver le meilleur compromis avec le temps d’exécution de chaque test. Ces tests sont présentés dans une configuration très classique utilisant Spring et JPA/Hibernate.
L’implémentation utilise une base HSQLDB et quelques bibliothèques pour faciliter l’écriture du code, en essayant de rester aussi léger que possible. Les tests sont isolés pour que vous puissiez activer l’exécution parallèle du plugin Surefire de Maven au niveau des classes de test. Vous pourrez facilement dériver l’implémentation nécessaire à isoler vos tests au niveau des méthodes si vous le souhaitez.

Lire la suite de cet article »

La plateforme Java EE conserve de nos jours encore une mauvaise réputation. Les fameux EJB 2 et conteneurs lourds démarrant en plusieurs minutes vous rappelleront quelques bons souvenirs. L’arrivée de Spring a ouvert la voie aux conteneurs légers, à l’inversion de contrôle, ou encore à l’injection de dépendances; et est devenue la solution de référence. Cependant, la plateforme Java EE a beaucoup évolué entre temps.

Nous allons voir que Java EE 6 n’a maintenant rien à envier à Spring. Cette plateforme est devenue légère et simple à prendre en main. Toutes les spécifications ne seront pas abordées en détails.  Nous parlerons plutôt de conteneurs légers et testables, de managed beans, d’EJB Lite, ainsi que des nombreux services et patterns offert par la plateforme.  Nous terminerons par la spécification CDI et ses extensions portables, qui offrent de belles perspectives à la plateforme Java EE 6.

Lire la suite de cet article »

Avec cette vidéo vous allez découvrir comment Kirk a procédé lors de cet atelier pour identifier les points d’amélioration d’un système et la manière de les résoudre. Tout cela sans préparation initiale ni code source : du live optimizing !
Écoutez également Kirk interviewé par Cyrille Le Clerc la veille de cet atelier.

Atelier performance avec Kirk Pipperdine [ 55:14 ] Download

La prochaine session du Paris Scala User Group aura lieu jeudi 26 Janvier à 19h30 dans les locaux de Xebia.

À cette occasion, Stéphane Landelle nous présentera Gatling qui est un outil de stress test écrit en Scala et reposant sur les frameworks akka et Netty. En seconde partie, il nous donnera un retour d’expérience sur l’utilisation de Scala pour développer l’outil.

Il reste encore des 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

Cyrille Le Clerc a profité du passage de Kirk Pepperdine à Paris pour l’interviewer sur les performances en Java ; au programme de ces discussions :

• Comment troubleshooter des problèmes de performances : les points d’entrées de l’investigation,
• Nouveaux langages sur la JVM : Scala, Clojure, …
• Cloud computing et virtualisation,
• JVM et appliances Java : Hotspot, jRockit, IBM J9, Azul, ExaLogic, …
• Support des large heaps : G1, Direct Memory, …
• … et quelques recommandations de programmation en Java.

Bonne écoute !

Interview de Kirk Pepperdine sur les performances en Java par Cyrille Le Clerc [ 36:12 ] Download

Combien de fois vous êtes vous senti engoncé dans votre frustration parce que vous étiez incapable d’utiliser des chaînes de caractères dans vos switch-case ? À défaut de pouvoir utiliser Java 7, une telle possibilité serait très utile pour par exemple traiter les arguments de votre application, pour analyser un fichier ou le contenu d’une chaîne. En fait, pour y arriver, vous devez écrire une série de if-else-if. Mais vous pourriez aussi utiliser une table de hachage, où les clés sont les chaînes de caractères et les valeurs sont les traitements réifiés par des Runnable, des Callable ou des Function de Guava.

Si le switch-case acceptant des chaînes de caractères est pour vous une chouette invention, le pattern matching de Scala nous indique que ce n’est pas suffisant ! En effet, il y a d’autres cas où une série de if-else_if-else_if… serait sympathiquement transformée en une sorte de structure plus ou moins équivalente au switch-case. Par exemple, ce serait bien de pouvoir simplifier une série de compositions entre des instanceof et des class cast enfermés dans cette série de if-else_if-… en vue de réaliser des traitements spécifiques selon le type d’un paramètre (en attendant le multi-méthode).

Dans cet article, nous allons voir ce que peut apporter le pattern matching de Scala dans différents cas.

Lire la suite de cet article »

Avant de commencer l’année 2012, je vous propose un petit quiz adapté d’un cas réel.

Un programme standalone parse un fichier et insère les données parsées dans une base de données. Le même programme est exécuté dans trois régions différentes à savoir l’Europe, l’Amérique et l’Asie. Les entités persistées ont toutes un champ uid unique. La valeur de ce champ doit être sous la forme ‘E-1234′ ce qui est interprété comme l’enregistrement n° 1234 d’Europe. La base de données est la même pour les trois régions.

Lorsqu’on lance le programme dans les trois régions en parallèle, une exception est levée, laquelle et pourquoi est-elle levée ?

Lire la suite de cet article »

Lors du XKE du mois de novembre, j’ai présenté une introduction à la programmation fonctionnelle. Cette présentation fût suivie d’une partie Hands On où les participants ont pu s’essayer (parfois dans la douleur, mais toujours dans la bonne humeur) à ce paradigme avec le langage Java. Je vous propose dans cet article un ensemble de solutions sur les exercices présentés. De quoi occuper vos longues soirées d’hiver.

Lire la suite de cet article »

Dans un récent billet, je vous ai présenté JPDA afin de résoudre le problème d’envoi de mail à l’interception des exceptions levées dans une application legacy. Dans cette deuxième partie de la série, je vous propose de résoudre le même problème avec l’API Java Instrumentation.

Lire la suite de cet article »

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 »