Integration Unit Testing in Action

An API seldom does its job alone. It works together with a database, a message queue or other APIs, and most of what it does is invisible in the HTTP response.

Integration Unit Testing (IUT) tests such an API as a black box, in isolation, verifying both its API spec and its side effects — the row written to the database, the message published to the queue, the downstream call made. For API testing, a single test case replaces the traditional combination of mock-based unit testing and API spec testing.

This series shows the method in practice, one technology at a time.

The articles

• MuleSoft — a Mule 4 Create Order API, tested against a stub PostgreSQL database and a stub ActiveMQ broker.

More technologies to come.

What each article contains

Each article is standalone and runnable on your own machine:

• An API under test, in its own GitHub repository.
• An API Test Base workspace holding the IUT test cases, in a separate repository.
• A walkthrough of two red-green cycles a developer runs as part of API development — testing a new API, then testing a change to it.

The method is the same everywhere

The technologies differ; the test case does not. In every article the shape is the same:

1. Stand up the stub dependencies and set them to a known state.
2. Call the deployed API.
3. Verify the response, and verify what actually landed in each dependency.

The test case knows the API’s contract — the request, the response, the table, the queue — and nothing about how the API is implemented. That is what lets the same approach cover a Mule flow, a Spring Boot service, or anything else that exposes an API and has side effects worth checking.