Imaginez la situation suivante : vous rajoutez tranquillement une nouvelle route dans votre application Java, (en architecture hexagonale bien sûr!), quand après avoir testé votre code, vous décidez de créer votre MR.

Oh non ! Plusieurs erreurs sur les tests… Regardons ça de plus près, ok ce sont.. des tests d’intégration qui ratent sur les autres routes du controller ? Etrange, mais bon, on va regarder ça.

Premiers checks #

Bon eh bien, que se passe-t-il ? On lance les tests en local, et les routes en questions nous renvoient des erreurs 400 (Bad Request).

Pourtant en regardant le code du test je cherche bien à lui envoyer un body et… le log retrofit le confirme, le body est bien envoyé.

Pourtant il semble qu’à la désérialisation, le body ne soit pas pris en compte. On regarde le code de la route, et on voit que l’annotation @RequestBody est bien présente.

Bizarre encore une fois, je met donc un breakpoint dans le code de la route, et… et bien je n’y parviens même pas. Le code n’est pas exécuté, et le test s’arrête avant.

Je cherche à ajouter des logs, à regarder si le test rentre dans le @PreAuthorize ou pas, mais rien n’y fait, impossible d’en savoir plus.

Alors c’est l’heure de l’auto review, je relis ma MR, mais… rien n’a été rajouté ou modifié pour ces routes (SPOILER: à première vue..).

La dernière étape c’est aller sur prod, et voir si le test passe et n’a pas été introduit par une autre MR. Les tests passent. Bon.

La piste #

Je me rend quand même compte en allant à nouveau sur ma branche que certains imports sont en rouge et qu’il faut donc que je regénère les sources.

Alors que je lance l’install via Maven, je vais dans un des fichiers, et l’IDE m’importe automatiquement des imports manquants, pour le coup, un assertThat qui n’est pas celui de AssertJ, mais d’un autre package.

Je modifie ça car cela n’a pas lieu d’être. Mais cela recommence 2 fois, jusqu’au moment où je me rends compte que… la sync maven vient de se terminer (et donc que les sources d’AssertJ sont maintenant disponibles).

Et si…

La révélation #

Je reviens dans le controller, je fais un petit git reset --soft HEAD~1 pour voir les modifications apportées dans la MR et… effectivement.

Que s’est-il passé ?

Quand j’ai commencé à écrire ma nouvelle route, j’ai du générer les sources avec Maven et je suis allé écrire du code dans le controller sans attendre que l’IDE ait fini de télécharger les sources.

En me rebasant sur la branche de production, une MR avait été créée pour bump la version de spring-boot.

Résultat des courses, les auto imports d’IntelliJ, confus, ont vu que j’utilisais un @RequestBody mais comme spring-boot n’était pas encore téléchargé, les controllers avaient une annotation @RequestBody de… Swagger. Donc la desérialisation était impossible.

Leçon apprise! Je ferai plus attention à mes imports lors de mes code reviews mais, je continuerai d’utiliser, les fabuleux imports automatiques d’IntelliJ, qui même s’ils m’ont frustré cette fois-ci, me font gagner un temps fou au quotidien.