• 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.

  • Passer des arguments au build de Docker

    Docker Moby

    Depuis quelques années, je gère un repository sur GitHub pour que chacun puisse faire un build à partir du code source de JBoss EAP. Récemment, j’ai voulu automatiser ce build avec Docker, sur plusieurs systèmes (Debian, CentOS, Alpine), pour plusieurs versions du JDK (8 et 11) et pour plusieurs versions de JBoss EAP.

    C’est là que j’ai découvert la possibilité d’utiliser des arguments dans Dockerfile et de les passer en option de docker build. Ainsi, je peux choisir les versions du JDK et de JBoss EAP au lancement du build :

    ~# docker build --build-arg JDK_VERSION=8 --build-arg EAP_VERSION=7.2.3     \
                    --tag hasalex/eap:7.2.3_jdk8 .

    Voyons pourquoi et comment j’en suis arrivé à ce résultat…​