All articles

· 3 min read

Testing APIs with Bruno: field notes

Two years of API test campaigns on a streaming platform: why we left Insomnia for Bruno, and what it changed for devs and QA alike.

  • QA
  • API
  • Tooling

I spent two years testing the APIs of ADN, an anime streaming platform. Full campaigns: authentication, subscriptions, Stripe payments, resume-playback. First with Postman, then Insomnia, then Bruno. This is the story of the last migration. The good one.

Insomnia, and the day it required an account

For a long time, Insomnia did the job. The interface is clean, environments are well designed, and for running a manual test campaign there was honestly nothing to complain about.

The problems were elsewhere.

First, the collection itself. Ours lived in a JSON export several thousand lines long, impossible to review, passed around through Drive under names like qa-collection-v3-FINAL.json. The person maintaining it was a single point of failure: when an endpoint changed, nothing flagged it. We would find out mid-campaign, at the worst possible moment.

Then in late 2023, Kong made accounts mandatory and turned on cloud sync by default. Logging in to open your own requests, and watching internal collections (staging URLs, tokens, test data) ship off to a third-party cloud? For a lot of teams that was the exit signal. It was for us too.

Plain-text files in the repo

Bruno takes the exact opposite stance: no account, no cloud, no binary format. Every request is a plain-text .bru file:

meta {
  name: Create subscription
  type: http
}

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

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

You can read it without opening any tool. More importantly: you can version it.

The collection lives with the code

This is where everything changed for us. The Bruno collection sits inside the repo, on GitHub, right next to the endpoints it covers.

In practice:

  • a dev changes an API contract? The .bru diff shows up in the same PR. If they forget to update the collection, it's caught in review, not three weeks later during a test campaign;
  • QA does a git pull and always works against the current version. No more file floating around, no more "do you have the latest collection?";
  • devs, QA, sometimes the PO checking a payload: everyone looks at the same file, with git history to tell who changed what, and why.

The test campaign became a deliverable like any other. It gets reviewed, it follows conventions, and it breaks in CI when it drifts from the code: Bruno's CLI runs in the pipeline with no license and no service account.

What I'm not selling you

Let's be honest for a minute. Bruno's interface is rougher than Insomnia's, a few comfort shortcuts are missing, and the .bru format is still a niche (your editor won't help you much outside the app). If you need a built-in mock server or advanced gRPC, you won't find them (yet).

But none of that outweighs the rest. A reviewable, versioned collection, shared between dev and QA in the same repo, evolving in the same PRs as the code: once you've worked that way, going back to a JSON export in a Drive folder is unthinkable.

Verdict

If your API tests still live on one person's machine, the real question isn't Insomnia versus Bruno. The real question is: is your test campaign code, or a file quietly going stale? Bruno finally makes the first option practical. That's all we ask of it.

About the author

Kabir Basheer Ahamed

Business analyst and full-stack developer at SnowPact. I design and build web products end to end, and write about what I learn along the way.

/about/contact