Tests d'API REST

Il existe deux façons de rater les tests d'une API Spring Boot, et elles se ressemblent moins qu'on ne croit.

La première est de ne pas en écrire. Personne ne l'assume, tout le monde la pratique un moment, et le symptôme est connu : chaque modification devient une négociation, parce que personne ne sait ce qu'elle casse.

La seconde est plus insidieuse parce qu'elle a l'apparence du sérieux. Tout est annoté @SpringBootTest, chaque test démarre le contexte complet, la suite prend onze minutes, l'équipe cesse de la lancer localement, et la moitié des tests vérifient que Spring sait mapper une URL — ce que Spring garantit déjà. On a payé le prix des tests sans en obtenir la valeur : une suite lente qu'on n'exécute plus ne protège de rien.

Le bon dosage vient d'une question simple, posée test par test : quel code, écrit par moi, ce test protège-t-il ? Si la réponse est « la logique de calcul de la date de retour », un test unitaire de quelques millisecondes suffit. Si c'est « la sérialisation, la validation et le code de statut de mon contrôleur », une tranche @WebMvcTest est l'outil adapté. Si c'est « ma requête JPQL fonctionne sur PostgreSQL », il faut un vrai PostgreSQL, et Testcontainers le fournit.