Java et les tests

mavenjenkinsjunitsonarqube

Imaginons une organisation qui se lance dans le développement Java et souhaite monter sa première plate-forme de développement Java. Que peut-on lui conseiller pour la partie tests ?

Lorsqu’on parle de test en Java un des premiers noms qui vient à l’esprit est JUnit. Puis on pense à l’intégration continue qui permet de tester la non régression au fil de l’eau, par exemple avec Maven (mais en fait Maven s’occupe surtout du build). Et enfin éventuellement à Sonar (qui s’appelle SonarQube depuis peu) pour la qualité logicielle, et à Test Director (maintenant HP Quality Center) pour la gestion de plans de tests. Et en poussant un petit peu on arrive à se souvenir qu’on pourrait faire de la gestion des exigences, par exemple avec DOORS. Ah oui, et aussi qu’il faut gérer les bugs, par exemple avec Mantis, Jira ou Bugzilla.

Améliorez les performances: Parallel processing with Camel & Spring (Partie 1/2)

Ce billet s’inscrit dans la catégorie optimisation des performances.

Il se fixe comme objectif d’illustrer avec démo détaillée comment améliorer significativement les performances de nos projets.

Et cela sans se lancer dans l’aventure d’écrire des kilomètres de code lourd de gestion du ‘parallel processing’ car nous allons laisser la puissance du framework Camel opérer.

Sachez néanmoins que de nombreux problèmes de mauvaise performance peuvent être traités sans recours aux implémentations complexes de parallélisme.

Voici deux situations où il faudrait réfléchir sur l’apport du parallélisme :

– Si les tâches ou opérations ne prennent que très peu de temps (échelle quelque sec). La gestion/monitoring des threads devient coûteux.

– Si les ressources mémoire, CPU et IO sont déjà fortement utilisées; sachez que le parallélisme consomme davantage de ressources.

Le billet veut s’inspirer (librement) des deux étapes décrites dans la démo du chapitre 10 du livre « Camel in action ».

L’essentiel du code source est fourni ici.

Sachez néanmoins que le code présenté ci-après a été largement adapté et pour certaines parties complètement réécrits.

En effet, comme j’utilise Spring, toutes les parties de code sont adaptées ou réécrites en fonction.

En particulier j’utilise l’implémentation spring ThreadPoolTaskExecutor de l’interface TaskExecutor à la place de la méthode statique de Executors de java.

Le billet est organisée en deux parties:

– La première partie permet d’exécuter en séquentiel notre démo,

– La seconde permet adapte la première partie pour une exécution parallèle.

Nous donnons quelques indications sur le temps d’exécution de chacune des parties.

Avec les bons paramètres nous pouvons diviser par quatre le temps d’exécution voire plus.

Le framework Camel offre avec son java DSL des fonctions permettant d’obtenir simplement de meilleurs performances en parallélisant les tâches.

Comme d’habitude nous le combinons avec le framework Spring v3+ car peut-on faire autrement?

Dans le domaine de performance, il est utile d’identifier les deux limites: CPU-bound et IO-bound.

Distinguer ces deux limites permet d’identifier le bon choix pour améliorer les performances.

En guise de conclusion, dans le domaine d’exécution parallèle, Camel simplifie grandement la vie des développeurs.

Néanmoins, il leur reste la responsabilité de la cohésion des données.

Passons à la mise en pratique.

Présentation, étape par étape, de Spring-DATA-JPA

Ce billet présente une démo pour illustrer, étape par étape, comment utiliser Spring-Data-JPA.

Ce billet peut être considéré traitant le même thème que Construction de requêtes en Java : comment faire le bon choix ?.

Nous détaillons, dans une première partie, la prise en main du « framework » Spring-Data-JPA avant de progresser dans notre compréhension.

Le projet Spring-Data-JPA est l’un des projets de Spring reposant sur Spring-Data.

Spring-Data réduit considérablement le coût économique de la couche d’accès aux données relationnelles ou NoSQL.

Il simplifie l’accès aux bases de données SGBDR ou de type NoSQL.

Spring-Data peut-être combiné avec le framework QueryDSL (Domain Driven Design) afin de réaliser des requêtes complexes.

Avec Spring-Data-JPA, le développeur bénéficie d’un certain nombre de méthodes d’accès à la base sans écrire une ligne de code d’implémentation.

Le projet Spring-Data-JPA vise à améliorer la mise en œuvre de la couche d’accès aux données en réduisant considérablement l’effort d’écriture du code d’implémentation en particulier pour les méthodes CRUD et de recherche.

La notion centrale dans Spring-Data-JPA est la notion « Repository ». Le repository est une interface à écrire par le développeur.

Il déclare, dans cette interface, les méthodes utiles d’accès aux données et Spring-Data-JPA fournit les implémentations nécessaires.

Notez que la même approche est appliquée à des contextes autres que JPA comme pour les bases non relationnelles.

Vous pouvez télécharger les sources de la démo1 ici.

Avec Spring-Data, écrire des méthodes de requête à la base se fait en 3+1 étapes:

  • Déclarer une interface Repository,
  • Ecrire la signature de la méthode de requête (CRUD ou de recherche),
  • Configurer Spring pour la génération automatique,
  • Appeler dans le client (ou test unitaire) les méthodes du Repository

C’est aussi facile!

Mais là on n’a fait que survoler la surface de Spring-Data.

Nous allons détailler ces étapes ci-après dans la démo.

Mylyn 3.5 – Intégration de Hudson dans Eclipse

La nouvelle version 3.5 du module Mylyn permet d’avoir accès à la plate-forme d’intégration Hudson directement depuis l’environnement de développement de Eclipse.

Ainsi plus besoin de sortir de Eclipse, toutes les informations sont disponibles depuis Eclipse :

  • l’état des jobs d’intégration est rafraîchi automatiquement dans Eclipse et une notification s’affiche indiquant si un build échoue
  • les résultats des tests du job sous Hudson s’affichent dans la vue JUnit comme s’il s’agissait de tests unitaires lancés en local.
  • les traces de la console du build Hudson sont affichées dans la vue console de Eclipse

Paramètres mémoire de la JVM pour le plugin maven-surefire-plugin

Chez Netapsys, nous mettons un point d’orgue à assurer la qualité de nos réalisations. Dans nos développements, les tests y sont pour beaucoup. Nous utilisons, pour les exécuter, le plugin Eclipse Junit. Et, dans le cadre de l’industrialisation de nos projets, ces tests sont lancés via Maven grâce au plugin maven-surefire-plugin.

Problème :
Récemment j’ai eu besoin de booster la mémoire de la JVM pour lancer un test assez gourmand en ressources. Et là, problème : alors que mon test passait sans problème sur Eclipse, il déclenchait à chaque fois une exception java.lang.OutOfMemoryError: Java heap space lorsqu’il était lancé via Maven, et ce malgré un paramétrage identique au niveau variables d’environnement.

[Paris JUG] Soirée spéciale Tests

Le 11 janvier 2011 a eu lieu le premier JUG de 2011, ayant comme thème: les Tests.
La soirée était animée par David Gageot, auteur du blog Java Bien!.

Lors de nos développements, nous avons tous été confrontés à écrire des tests. Un bon développeur doit écrire des tests fonctionnels et/ou unitaires de façon régulière. Mais s’il y a beaucoup de tests, le build prend plus de temps. Du coup, nous perdons du temps sur la suite du développement.

La question est: Comment faire des tests rapides et efficaces ?