Le "property based testing" est un type de tests souvent utilisé en programmation fonctionnelle pour valider des lois. Il y a quelques années, j'avais testé jqwik, une librairie de property based testing en java, pour valider des lois sur une lib d'optics en java (ouais je sais, ça à l'air de ne rien vouloir dire cette phrase). Je n'étais pas allé plus loins que ça.

Cette année à Devoxx France 2025, j'ai assisté à un talk de Pierre Zemb "Et si on faisait du simulation-driven development ?" dans lequel il évoquait le property based testing pour tester du code métier.

Voyons ce que ça peut donner en java pour tester une application spring.

À la MAIF, le flow de dév le plus communément appliqué, c'est du gitflow et du scrum. Personnellement, j'ai du mal à comprendre le gitflow et je ne comprends pas à quoi sert la branche develop du moins pour le développement d'application. Les branches support ne sont pas utiles car, on ne maintient qu'une version de notre application à un moment donné. J'ai également l'impression que la branche master et develop finissent obligatoirement par avoir un historique divergent, à moins de rebase develop à partir de master de faire un force push.

En ce qui concerne le scrum, je trouve que ça génère une pression continue, on est toujours en train de se prendre la tête sur les stories pour savoir si ça va rentrer ou non dans le sprint. Ça n'est pas très chill comme méthode.

Depuis quelques années sur notre projet, nous avons mis en place un flow un peu atypique à base de trunk base. C'est ce que je vais vous présenter ici.

Dans les langages fonctionnels tels que java ou haskell, il est d'usage d'utiliser au maximum le compilateur pour éviter le plus tôt possible les bugs.

Avec l'arrivée du jdk 17, et notamment des sealed class et des record, java nous propose de nouvelles fonctionnalités pour utiliser encore plus le système de type et donc le compilateur.

L'approche "parse, don't validate" propose de créer des types riches pour représenter les données plutôt que d'utiliser les types primitifs comme String, Boolean etc et ainsi rendre impossible les états incohérents. Dans le cas d'une API, une fois le payload d'une requête parsé, c'est le compilateur qui reprend la main et valide le code pour vous.

Dans cet article, je vous propose, de suivre cette pratique en java et de voir où ça nous mène.