Exploring Bruno for API Exploratory Tests

Why I Looked Beyond Postman for API Testing

Before now, I liked using Postman for my API exploratory tests, automating API flows, and end-to-end checks. For most of my needs, it was quite good. I didn't want to have to use Cypress, Playwright, or Rest Assured because I preferred the GUI interface Postman provided. It allowed me to explore APIs interactively while still writing automated test scripts for scenarios I deemed fit.

Understanding API Exploratory Testing

For context, exploratory testing - in the context of APIs - involves interacting with endpoints while simultaneously learning about system behavior, designing tests, and spotting issues. It often happens before writing automated checklists or deeper tests, and plays a critical role in understanding a product's quality and reliability.

Having the right tool for this process can significantly impact development efficiency and API test automation quality.

Postman Limitations for API Testing Workflows

Postman covers many of the API testing needs that Cypress or Rest Assured might be used for. However, I began to run into some limitations that affected my workflow. A few of the challenges I encountered include:

Collection Management Issues

Exporting collections: After writing tests, I had to export the entire collection - including test scripts - into a JSON file before running them via Newman (Postman's CLI runner).

Note: While Postman does have a built-in collection runner, the cloud-based runner is limited to 25 runs per month on the free plan. Local execution via Newman or the desktop Collection Runner doesn't have this limitation.

Cloud Dependency Challenges

Cloud dependency for collaboration: Postman collections are usually managed through the Postman cloud platform. While this makes collaboration and real-time syncing easier with team members, it introduces a dependency on their servers.

You can work locally with exported collections, but you lose features like syncing, commenting, and shared environments.

CLI Execution Limitations

CLI granularity: It wasn't possible to run a single request via the CLI using Newman. I had to run the entire collection or folder.

This contrasts with tools like Cypress or Playwright, where you can isolate and run individual test files or specific test cases.

Because of these limitations, I started looking for an alternative - something that offered the flexibility I enjoyed with Cypress or Playwright for automated checklists, but specifically designed for API testing. That's how I discovered Bruno, thanks to a Reddit thread.

Getting Started with Bruno API Testing Tool

Bruno's documentation was easy to follow, especially coming from Postman. One thing that caught my interest was its file-based structure - every request is saved as a .bru file inside folders, just like working with regular files in your codebase. This made version control and collaboration using Git feel natural.

Bruno's API Testing Features

Scripting Capabilities

Like Postman, Bruno supports scripting, and it comes with inbuilt libraries like axios (which simplifies making HTTP requests within scripts) and chai (for assertions). These libraries can be used in pre-request scripts (code that runs before a request is sent) or test scripts (code that validates response data).

Dedicated Testing Architecture

A significant advantage that drew me to Bruno is its dedicated Tests tab, which keeps testing logic separate from pre-request and post-request scripts. This clear separation of concerns makes test scripts more organized and easier to maintain compared to Postman's single script section approach.

Powerful CLI Integration

Another big win: running tests via CLI was dead simple. You can execute collections, folders, or individual request files, all using the bru CLI:

To run an entire collection:

bru run ./ -r --env "Todo App" --output test-results.html --format html

To run a folder:

bru run ./auth -r --env "Todo App" --output auth-results.html --format html

To run a single request file:

bru run ./auth/login.bru -r --env "Todo App"

This kind of granularity was exactly what I was looking for - something that made it easy to run specific test units, just like in a Cypress or Jest testing setup. Bruno's CLI integrates well into CI/CD pipelines too, and it generates reports in formats like HTML, making it suitable for automation.

Bruno's Local-First Architecture

Bruno operates with a local-first philosophy, eliminating cloud dependencies while still enabling team collaboration through standard version control systems like Git. This approach aligns well with modern development practices and makes it particularly appealing for teams already using Git for their codebase.

Bruno Considerations and Potential Limitations

While Bruno offers many advantages for API testing, it's worth noting a few considerations:

• As a relatively newer tool, Bruno has a smaller community and ecosystem compared to Postman.
• There are fewer third-party integrations available at this time.
• The learning curve may be steeper for non-technical team members who are used to Postman's interface.

That said, if you're already using Postman and thinking of giving Bruno a try, Bruno provides a surprisingly smooth import of Postman collections, tests, and scripts - translating them into Bruno's structure with minimal adjustment. This makes it easier to experiment without losing prior work.

Migration from Postman to Bruno

The migration process from Postman to Bruno is straightforward:

1. Export your Postman collection as a JSON file
2. Import it into Bruno using the import feature
3. Bruno automatically converts your Postman requests, tests, and scripts into its format

This seamless transition lowers the barrier to trying Bruno alongside your existing Postman workflow.

REST API Testing Workflow with Bruno

When performing REST API testing with Bruno, the workflow typically involves:

1. Creating a new collection for your API project
2. Setting up environment variables for different testing environments
3. Creating requests for each endpoint you want to test
4. Adding pre-request scripts for authentication or data setup
5. Writing test scripts to validate responses
6. Running tests individually or as collections

This workflow mirrors what you might be familiar with in Postman but with the added benefits of Bruno's file-based structure and CLI capabilities.

Final Thoughts on API Testing Tools

My goal here isn't to pit Bruno against Postman. Both tools are great in their own right:

• Postman is excellent for teams, especially those that rely heavily on its collaborative features and ecosystem.
• Bruno shines when you want a lightweight, version-controlled, local-first API testing tool that behaves like a developer's tool and integrates smoothly into CI/CD.

If you're curious and want to compare how API checklist automation looks using both tools in a real project, here are two repositories I created using a simple todo application:

• Bruno: https://github.com/ovansa/todo-api-test-bruno
• Postman: https://github.com/ovansa/todo-api-test-postman

For more information about Bruno and to get started, visit their official website: https://www.usebruno.com/

Feel free to clone, run, and experiment with both approaches!

Conclusion: Choosing the Right API Testing Tool for Your Needs

The choice between Bruno and Postman ultimately depends on your specific requirements and workflow preferences. If you value Git integration, local-first operation, and powerful CLI capabilities, Bruno might be worth exploring. If you prioritize a mature ecosystem and extensive collaboration features, Postman remains an excellent choice.

Whatever tool you choose, the goal remains the same: efficient, reliable API testing that integrates well with your development process. Both Bruno and Postman can help you achieve this goal, albeit with different approaches and trade-offs.

Have you tried Bruno for your API testing? What has been your experience? I'd love to hear your thoughts in the comments below.