Tester ses APIs avec Bruno : retour d'expérience

J'ai passé deux ans à tester les APIs d'ADN, une plateforme de streaming d'animé. Des campagnes entières : authentification, abonnements, paiement Stripe, reprise de lecture. D'abord avec Postman, puis Insomnia, puis Bruno. Cet article raconte la dernière migration. La bonne.

Insomnia, et le jour où il a fallu un compte

Pendant longtemps, Insomnia a fait le travail. L'interface est propre, les environnements sont bien pensés, et pour dérouler une campagne de recette à la main, franchement, rien à redire.

Les problèmes étaient ailleurs.

D'abord la collection elle-même. Chez nous, elle vivait dans un export JSON de plusieurs milliers de lignes, impossible à relire, qu'on se passait via Drive avec des noms comme collection-recette-v3-FINAL.json. La personne qui maintenait la collection était un point de défaillance unique : quand un endpoint changeait, rien ne le signalait. On le découvrait en pleine campagne, au pire moment.

Et puis fin 2023, Kong a rendu le compte obligatoire et activé la synchro cloud par défaut. Devoir se connecter pour ouvrir ses propres requêtes, et regarder des collections internes (URLs de préprod, tokens, données de test) partir vers un cloud tiers ? Pour beaucoup d'équipes, ça a été le signal de départ. Pour nous aussi.

Des fichiers texte dans le repo

Bruno prend le contre-pied exact : pas de compte, pas de cloud, pas de format binaire. Chaque requête est un fichier .bru en texte clair :

meta {
  name: Create subscription
  type: http
}

post {
  url: {{baseUrl}}/subscriptions
  body: json
}

assert {
  res.status: eq 201
  res.body.status: eq "active"
}

Ça se lit sans ouvrir le moindre outil. Et surtout : ça se versionne.

La collection vit avec le code

C'est là que tout a changé pour nous. La collection Bruno est dans le repo, sur GitHub, à côté du code des endpoints qu'elle teste.

Concrètement :

• un dev modifie un contrat d'API ? Le diff des .bru apparaît dans la même PR. S'il oublie de mettre la collection à jour, ça se voit en review, pas trois semaines plus tard en campagne de recette ;
• la QA fait un git pull et travaille toujours sur la version à jour. Plus de fichier qui circule, plus de « tu as la dernière collection ? » ;
• devs, QA, parfois le PO qui veut vérifier un payload : tout le monde regarde le même fichier, avec l'historique git pour savoir qui a changé quoi, et pourquoi.

La campagne de tests est devenue un livrable comme un autre. Elle se review, elle suit des conventions, et elle casse en CI quand elle n'est plus alignée avec le code : le CLI de Bruno tourne dans le pipeline sans licence ni compte de service.

Ce que je ne vous vends pas

Soyons honnêtes deux minutes. L'interface de Bruno est moins léchée que celle d'Insomnia, il manque quelques raccourcis de confort, et le format .bru reste une niche (votre éditeur ne vous aidera pas beaucoup en dehors de l'app). Si vous cherchez un mock server intégré ou du gRPC avancé, vous ne les trouverez pas (pas encore).

Mais aucun de ces points ne pèse face au reste. Une collection relisible, versionnée, partagée entre dev et QA dans le même repo, qui évolue dans les mêmes PRs que le code : une fois qu'on y a goûté, revenir à un export JSON dans un Drive est inconcevable.

Verdict

Si vos tests d'API vivent encore sur le poste d'une seule personne, le vrai sujet n'est pas Insomnia contre Bruno. Le vrai sujet : votre campagne de tests est-elle du code, ou un fichier qui se périme en silence ? Bruno permet enfin de choisir la première option. C'est tout ce qu'on lui demande.