-
Afficher un historique avec Hibernate Envers
Sur un projet en cours, on stocke l’historique complet des modifications sur les entités. Le projet utilise les frameworks classiques: Spring Boot 3 et JPA / Hibernate 6. Nous avons ajouté Hibernate Envers pour stocker les changements dans des tables d’audit.
@Entity @Audited(withModifiedFlag = true) public class Product extends AbstractEntity<UUID> { ... }
La façon d’enregistrer ces modifications est bien documentée, je n’y reviendrai pas. Pour ce projet, nous avons voulu ajouter une façon générique d’afficher l’historique des changements pour chaque instance d’entité.
-
Retour d'expérience, migration à Spring Boot 3
Ces dernières semaines, j’ai dû faire une migration de Spring Boot 2 à Spring Boot 3. Comme dans Spring Boot il y a toute une suite de frameworks et librairies, avec en particulier Spring Framework, Spring Security, Hibernate, ça fait pas mal de galères potientielles.
J’ai lu quelques articles et billets sur le sujet, en particulier le guide de migration du projet Spring. J’en ai conclu que ça n’allait pas être très compliqué, avec surtout un gros rechercher/remplacer de
javax.*
pourjakarta.*
. Evidemment ça ne s’est pas passé aussi simplement que prévu, c’est ce que je vais raconter ici. -
Tests d'intégration, comment vérifier que le ménage a été fait ?
Encore un billet sur les tests, et plus précisément sur les tests d’intégration en Java. Dans ma mission actuelle, il y a beaucoup de tests d’intégration, trop à mon goût. Et ce sont généralement des tests avec une intégration complète : le test envoie une requête HTTP à laquelle le backend testé renvoie une réponse construite avec des données issue d’une base de données de test.
Pour les faire fonctionner de façon reproductible, aussi bien en local qu’en intégration continue, ça demande quelques contorsions. J’ai donc cherché des idées pour les améliorer.
Aujourd’hui, je vais vous expliquer ce qu’on a fait pour résoudre le problème du ménage dans les données.
-
Comment vérifier l'envoi d'e-mails en test d'intégration ?
En avril, je traitais le sujet de la date dans les tests. Je continue sur ma lancée avec les tests, mais cette fois-ci il s’agit de tests d’intégration et de l’envoi d’e-mails.
Lorsqu’une application envoie des e-mails, ses tests d’intégration doivent d’une part avoir accès à un serveur SMTP, mais ils doivent aussi pouvoir valider que les messages envoyés sont conformes aux attentes. Nous allons aborder ces deux aspects.
-
Une histoire de temps et de tests
Le temps, c’est compliqué, ça change tout le temps. Et je ne parle pas de météo, mais bien du temps qui passe. Et c’est justement parce qu’il passe que ça change.
Bon, je vais m’arrêter là avec les pensées profondes. Je n’ai pas prévu de marquer l’histoire de la philosophie avec ce billet. Ce qui m’intéresse ici, c’est de pouvoir tester des méthodes qui utilisent des objets temporels, et plus précisément des objets du package récent
java.time
:Instant.now()
,LocalDateTime.now()
,ZonedDateTime.now()
,…Partons sur ce petit exemple, dans lequel on choisit une activité distincte en fonction de l’heure de la journée.
public class ActivityService { private final Action action; public ActivityService(Action action) { this.action = action; } public void chooseActivity() { if (LocalDateTime.now().get(ChronoField.AMPM_OF_DAY) == 0) { action.doSleep(); } else { action.doPlay(); } } }
En utilisant le code tel quel,
action.doSleep()
est appelé si le test est exécuté le matin etaction.doPlay()
si le code est appelé l’après-midi. Voyons comment adapter le code pour qu’on puisse développer tester de façon reproductible.