RecUnitTest : enregistrer pour mocker

Un petit article pour présenter ce petit développement https://github.com/niclange/RecUnitTest toujours à base d'AOP et pour l'instant uniquement pour une application utilisant le framework Spring. Je compte bien faire une version JEE.

L'objectif de cette librairie et d'aider à réaliser des tests unitaires de non régression sans faire de mock avec une libraire de type EasyMock ou Mockito. Elles sont très bien mais c'est toujours coûteux de réaliser des mocks quand parfois on peut l'éviter.

Voici le scénario pour utiliser RecunitTest :

Vous avez un développement qui utilise par exemple des service tiers (web ou autre) voir une base de données (mais normalement avec DBUnit ce cas est couvert). Il peut jouer en local les tests unitaires de type "intégration" qui utilisent donc de vrais services tiers fonctionnels (mais dédiés aux développements) au cours de son exécution, il doit savoir préalablement que les environnements sont fonctionnels et en état pour réaliser les cas de test. Mais sur la PIC, typiquement avec un Jenkins les tests seront lancés n'importe quand et il est compliqué et coûteux de maintenir des environnements uniquement pour ces tests.

Bref l'idée est d'enregistrer le comportement des réponses des environnements tiers, lors d'un tire de test unitaire maîtrise, dans un fichier pour être à même de le rejouer sur la PIC. De plus pour de la non régression ce fichier pourrait être utilisé dans le cas où remonter des environnements nécessaires est coûteux.

Pour réaliser cela j'ai mise en oeuvre :

• l'AOP Spring pour intercepter les méthodes à enregistrer et à rejouer.
• J'utilise une base clé / valeur embarquée mapdb pour stocker les données dans un fichier.
• Un parser JSON mais peut-être que je pourrais m'en passer...

Donc le développement est assez simple, la mise en œuvre complète sur un projet peut-être un peu plus complexe et nécessite de l'organisation. Je pense qu'il faut s'appuyer sur les profils maven (dans le pom) pour piloter la configuration de l'outil c'est à dire son mode : Record ou Play et le fichier de stockage qu'il faudra probablement pousser au travers du gestionnaire de configuration.

Je n'ai pas réalisé de tests avec un application massivement multi-thread mais j'ai essayé de prendre en compte cette problématique dans les développements. 

Bref il me reste encore à l'utiliser dans un cas réel et voir comment cela se passe pour donner plus de détails.

Logger les performances avec l'AOP dans une application n-tiers (Java)

La perf, un sujet incontournable, il sera mis tôt ou tard sur la table. Il faudra comprendre, améliorer, supprimer les points de contentions. Pour cela il est indispensable de réaliser des mesures. Un panel de solutions permettent de réaliser des mesures avec plus ou moins de finesse, dans diverses conditions.

Du temps d'exécution d'un test unitaire à un test de charge avec SoapUi ou JMeter, à une analyse de la jvm avec VisualVM ou Java Mission Control . Enfin en combinant tout ça on est certain d'arriver à une mesure fine et à identifier les axes d'optimisation. Mais à quel prix, ces outils on un coup non négligeable de mise en œuvre, et la traque prend du temps.

Une solution simple permettant de réaliser des rapports est la mise en place d'un logger par AOP s'appuyant sur l'architecture en couche (oui votre application est architecturée en couche). L'architecture en couche permettra l'utilisation de l'AOP de façon assez simple en interceptant les interfaces de chaque couche, et cela permettra de structurer le rapport. Cette approche est assez rapide et simple à mettre en oeuvre.

Pour cela j'ai développé un mini projet Log4Tiers (https://github.com/niclange/Log4Tiers) pour réaliser ces logs de performance, oui il est très simple et probablement beaucoup l'ont déjà implémenté. Il s'appuie sur Spring pour la mise en œuvre de l'AOP. On se place dans un contexte web, on va donc réaliser un log en tentant de suivre chaque appel au travers d'un identifiant (en rapport avec le thread), puis on identifiera chaque couche appelée et chaque méthode et les temps consommées.

Le plus complexe pour la mise en oeuvre est la configuration Spring de l'AOP.

Attention le fait de logger à un coût, et aura une impacte non négligeable, surtout si on log les éléments ayant une fine granularité, il faut donc en tenir compte, configurer la configuration AOP Spring en conséquence.

Vous trouverez un exemple complet dans la partie test unitaire du projet.

Je vais finir en ajoutant comment traiter le résultat du logger avec Excel.

On ouvre le fichier csv avec excel et on ajoute les entêtes des colonnes

En suite on peut réaliser un tableau croisé dynamique pour faire ressortir par exemple chaque appel :

Ou les couches de l'application :

A partir de là on peut réaliser toutes sortes de graphiques.

Sinon j'ai mis à jour le projet pour activer/désactiver les loggers par JMX.