-
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. -
Quand est-ce qu'on change d'heure ?
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
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 dedocker 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…
-
Combien de temps dure une semaine ?
Tout le monde sait qu'une semaine dure 7 jours ! Et même en Java, c’est simple à vérifier.
LocalDate start = LocalDate.parse("2000-01-01"); System.out.println( ChronoUnit.DAYS.between(start, start.plus(1, ChronoUnit.WEEKS)) ); // => 7 jours
Si on prend un peu de recul, on peut se rappeler que le calendrier révolutionnaire français avait une semaine de 10 jours. Ça prouve que la durée de 7 jours est arbitraire et qu’il n’est pas exclu que des calendriers s’en éloignent. Et quand on parle de la durée d’un mois ou d’une année, les exemples sont plus faciles à trouver avec les calendriers lunaires.
Voyons comment ça peut se traduire pour un développeur Java…
-
J'aime pas les custom repositories
On parle de Spring Data JPA, dont le but est de simplifier le développement de requêtes JPA. On y implémente un accès à une base de données relationnelle en déclarant quelques méthodes aux noms bien choisis dans des interfaces, ou en ajoutant des requêtes JPQL via des annotations.
Bref, avec les repositories de Spring Data JPA, on ne fait plus de code. Sauf si ce qui est proposé en standard ne suffit pas et dans ce cas il faut faire des custom repositories. C’est précisément ça que je n’aime pas.