API testing guides — test REST and GraphQL APIs, write contract tests, and automate API validation.
API Testing
The Postman Collection Runner lets you execute an entire collection of API requests in sequence, with test assertions, environment variables, and iteration support — all from the Postman GUI. It's the starting point for API test automation before you move to CLI tools like Newman. Opening the Collection Runner
API Testing
Most Postman users write basic tests — pm.response.to.have.status(200) — and call it done. Postman's scripting layer goes much deeper: pre-request scripts that generate dynamic data, test scripts that chain requests, and data-driven testing that runs a collection against hundreds of inputs. This guide
Test Automation
JavaScript tests that make real HTTP requests are slow and unreliable. Manual mocks for fetch or axios require constant maintenance as APIs evolve. Polly.js solves both problems by recording real HTTP interactions and replaying them in subsequent test runs — giving you test speed and isolation without sacrificing the accuracy
API Testing
API testing benefits from the same systematic input analysis as any other testing, but the input space is more structured: path parameters, query parameters, headers, and request bodies — each with their own validation rules and boundary conditions. This post applies BVA and equivalence partitioning specifically to REST API inputs. The
Security Testing
Web application security testing with Burp is intuitive when there's a browser to proxy. API testing requires a different setup — no browser, no HTML rendering, just HTTP requests and JSON responses. Burp handles this well, but the workflow is different. This guide covers authorized security testing only. Test
API Testing
If you've ever dealt with Postman's cloud sync forcing you to log in, its collection format being a massive JSON blob that makes Git diffs unreadable, or the frustration of your entire team's API workspace living in a proprietary cloud — Bruno was built to
Testing
GraphQL presents a unique challenge for contract testing. REST APIs have stable URL paths and HTTP verbs — easy to record as contracts. GraphQL routes everything through a single endpoint (POST /graphql) with the operation in the request body. The schema is flexible and self-describing. So where does contract testing
Python
Behave and the Python requests library are a natural pairing for API testing. You write scenarios in plain Gherkin that non-developers can read, while step definitions handle the HTTP calls. This post walks through project setup, reusable context objects, authentication flows, and error-case testing — all with working code.
Testing
Provider verification is the other half of the contract testing equation. Consumers write pacts that describe what they need. Providers verify those pacts against their real implementation. This guide covers the Python side of that workflow using pact-python and pytest. How Provider Verification Works When you run provider verification,
Contract Testing
Pact and OpenAPI both prevent API integration failures, but they solve different parts of the problem. OpenAPI defines the contract — the shape of requests and responses. Pact verifies that specific consumer interactions are honored by the provider. Used together, they cover each other's blind spots. This guide shows
Testing
Consumer-driven contract testing solves one of the trickiest problems in distributed systems: how do you know that changes to a provider API won't silently break every consumer that depends on it? Schema validation tells you the shape of a response. Contract testing tells you whether the response
Testing
Generating a Pact contract locally is a useful proof of concept. But contracts only deliver their value when they're shared automatically between teams, versioned alongside code, and verified on every pull request. That's what the Pact Broker is for. This post covers running a Pact Broker,