Les jeux de données font partie intégrante des tests. Elaborer un jeu de données demande une connaissance fonctionnelle, aussi bien sur la nature des données que sur le scénario de test envisagé. Utiliser des jeux de données réalistes participe à la compréhension du scénario de test et, donc, à sa documentation.
S’il vous était possible de générer ces fameux jeux de données, seriez-vous intéressés ?C’est précisément l’objet de ce billet et d’un modeste outil baptisé JavaBean Marshaller.
Continuer la lecture
Archives de l’auteur : Antoine
Ces outils qui nous font gagner du temps
Au quotidien, tout développeur Java utilise un IDE, un JDK, un outil build et un navigateur. Ce sont des standards. A côté, chaque développeur utilise un ou plusieurs petits outils permettant d’améliorer son quotidien. Par outil, j’entends aussi bien un plugin, un logiciel ou une fonctionnalité avancée de son IDE.
Dans cette présentation, j’ai eu envie de partager des outils fonctionnant sous Windows (mais pas que). J’utilise certains depuis des années, d’autres depuis seulement quelques semaines suite aux recommandations de collègues.
A vous de voir si vous souhaitez les tester puis les adopter, ou non.
Tester unitairement une application Java
Un récent 13-14 m’a donné l’occasion de partager ma vision des tests unitaires avec mes collègues, qu’ils soient développeurs Java ou chefs de projet.
Au cours de cette présentation, j’ai essayé de répondre à des questions qui font régulièrement débat : « Qu’est-ce qu’un test unitaire ? A quoi çà sert ? Que dois-je tester ? ». Tester n’est pas facile. Cela demande un apprentissage. Heureusement, il existe des bonnes pratiques et des outils. J’y ai notamment présenté ceux faisant parti de notre stack technique : JUnit, Mockito, DbUnit et Spring Test.
Des exemples de code ont illustré cette présentation dont voici librement le support :
Spring Core 4.2 Certification Mock Exam
Four years ago, I’ve published a first mock exam for the Spring Core 3.0 Certification. Encouraged by Michael and Alan, I’ve updated this free mock exam for the Spring Professional certification based on the Spring Core 4.2 course.
According to the Core Spring 4.2 Certification Study Guide, 3 new topics have been added to the Spring Core 4.2 mock exam: REST, Microservices and Spring Cloud. They replace older topics: JMX, JMS and Remoting.
Les dessous du Framework Spring
Chaque jour, de nombreux développeurs utilisent le framework Spring pour l’injection de dépendances et la gestion des transactions. Majeures, ces 2 fonctionnalités ne nécessitent pas un gros effort d’apprentissage. Pour autant, leurs mises en œuvre par le framework est complexe. Par curiosité intellectuelle, mais également afin d’éviter certains pièges et de profiter pleinement des capacités de Spring, il est intéressant de comprendre les mécanismes internes du framework qu’on utilise au quotidien : cycle de vie d’un bean, proxy, intercepteur, post-processeur, fabrique de beans, hiérarchie de contextes, portée …
Les slides de cette présentation ont pour objectif de vous les introduire.
Formatez votre code
Lors du démarrage d’un projet sur lequel plusieurs développeurs vont être amenés à travailler, se pose très tôt la question des styles et règles de formatage à appliquer au code. En effet, afin de pouvoir comparer l’historique des révisions d’un fichier, une bonne pratique veut que l’on ne change pas les règles de formatage au cours de route. Si tel était le cas, les changements importants seraient noyés par les changements d’indentations et autres retours à la ligne.
Parmi les normes de développements d’une entreprise ou d’un projet Open Source, un chapitre couvre généralement les règles de formatage. C’est par exemple le cas du guide de style de code du projet Spring Framework. Ces règles peuvent également être définies au sein d’un outil de qualimétrie comme SonarQube. Chaque violation de règle entraine alors un défaut.
Ce billet propose 2 solutions permettant à des développeurs IntelliJ, Spring Tools Suite (STS) et Eclipse de travailler ensemble.
Tout sur le Elastic{ON} Tour Paris 2015
Sur les 12 représentations mondiales, la 3ième date de la tournée européenne de la conférence Elastic{ON} a eu lieu le 5 novembre 2015 à Paris.
Invité par la société Adelean, j’ai pu y participé. Pour toutes celles et ceux qui n’ont pas eu cette chance, ce billet me permet de vous faire partager cette journée.
Docker file de la database MusicBrainz
Lorsqu’on développe dans son coin une démo basée sur une nouvelle techno, il est fréquent d’avoir besoin de données de tests. Soit on se les construit à la main, soit on en récupère sur Internet. Le mouvement Open Data et les API mises à disposition par les grands du Web permettent de récupérer des données en temps réel. Dans les conférences, nombre de démos live utilisent les API de Twitter ou de Github. Ces données sont généralement formatées en JSON. Une connexion réseau est alors nécessaire.
Dans le cadre d’une série d’articles sur Elasticsearch et AngularJS, j’ai eu le besoin d’indexer des données de manière offline. Cherchant une source de donnée musicale, j’ai opté pour MusicBrainz qui, à l’instar d’IMDb pour le cinéma, est une plateforme ouverte collectant des méta-données sur les artistes, leurs albums et leurs chansons puis les mettant à disposition du publique. Cette plateforme est composée d’une base de données relationnelles et d’une interface web permettant d’effectuer des recherches, de consulter les données et de participer à l’enrichissement de la base. Last.fm, The Guardian ou bien encore la BBC s’interfacent avec MusicBrainz.
Dans l’article Elastifiez la base MusicBrainz sur OpenShift, je proposais 2 méthodes pour installer la base de données : récupérer une VM ou un dump de la base PostgreSQL. Dans les 2 cas, la procédure d’installation demandait une intervention humaine.
Ce billet vous en propose une 3ième : automatiser l’installation de base de données à l’aide de Docker. Après quelques lignes de commande et un peu de patience le temps de l’import du dump PostgreSQL, vous pourrez vous connecter localement à la base musicale contenant des données à jour.
Hibernate Validator 5 sur un conteneur de Servlet 2.5
Implémentation de référence de Bean Validation 1.1, Hibernate Validator 5.x requière une implémentation d’Unified Expression Language respectant la JSR-341 (correspond aux EL 2.2).
EL 2.2 étant apparue avec Java EE 6, il n’est donc pas possible d’utiliser Hibernate Validator 5 dans un serveur d’application Java EE 5 et un conteneur de servlets 2.5. C’est pourquoi Hibernate Validator 5 ne fonctionne pas avec Tomcat 6.
Essayer et vous tomberez au runtime sur l’exception suivante :
NoSuchMethodError: javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory)
Benchmark de frameworks de mapping objet
Ce billet a pour origine un commentaire posté dans mon précédent billet et dans lequel Laurent demandait un retour d’expérience sur l’utilisation de frameworks Java de mapping objet vers objet tels Dozer ou ModelMapper.
Dans l’architecture d’une applicative n-tiers, une couche de mapping objet / objet peut intervenir à plusieurs niveaux :
- En entrée ou en sortie d’un web service SOAP afin de convertir en objet métier les DTO générés à partir du WSDL, ou inversement.
- Entre la couche de présentation et la couche de services métiers lorsque la première expose des DTO et la seconde travaille avec des objets métiers.
- Entre la couche de services métiers et la couche d’accès aux données afin de mapper les entités persistances en objets métiers.
Dans le premier exemple, le développeur n’a guère le choix. Dans les 2 autres, il s’agit d’un choix d’architecture.
L’introduction d’une couche de mapping n’est pas un choix à prendre à la légère : ayant pour objectif de découpler les couches, elle complexifie l’application et peut détériorer ses performances. Le choix d’en introduire une et d’utiliser un framework pour faciliter sa mise en œuvre n’est pas non plus évident.
Ce billet est découpé en 2 parties :
- Une première dressant les avantages et les inconvénients d’utiliser Dozer par rapport à une approche manuelle,
- et une seconde présentant les résultats d’un micro-benchmark comparant plusieurs frameworks : Dozer, Orika, Selma, MapStruct et ModelMapper.