• Retour d'expérience, migration à Spring Boot 3

    Spring Boot logo version 2 to version 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.* pour jakarta.*. 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 ?

    JUnit 5 logo with database

    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 ?

    mailbox

    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

    clepsydre

    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 et action.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.

  • Quand est-ce qu'on change d'heure ?

    clock daylight

    C’est assez facile à retrouver. Nous passerons à l’heure d’été le dernier dimanche de mars, à 2h00, puis nous repasserons à l’heure d’hiver le dernier dimanche d’octobre, à 3h00.

    Ce qui m’intéresse c’est que mon code puisse connaitre cette information. Et comme je veux gérer ça dans mon backend en Java, voyons voir ce que les APIs du JDK proposent.

    TLDR Toutes les informations sont disponibles via des méthodes publiques depuis le JDK 8, dans le package java.time.