End-to-end API testing, from sign-in to the final check

What end-to-end API testing covers

An end-to-end API test calls your backend the way a client does and lets every layer do its work: the gateway, authentication, the services, the database, the background jobs. Nothing is mocked inside the system under test. That is what makes it valuable, and what makes it slow and fragile when done carelessly.

Compared with tests through the browser, end-to-end tests on the API are faster and less flaky, and they test the rules that matter most: who may do what. They don’t test how the screens look.

Sign in like your users

The most common shortcut is also the most expensive: testing with one service token that may do everything. Such tests can’t find access bugs, and they skip the sign-in, which is the step that breaks most visibly.

• Use a test account per role, with the role’s real permissions and tenant.
• Sign in the way that role does: OAuth or OpenID Connect, a login form with a CSRF token, single sign-on, a second factor.
• Keep credentials out of the test code and out of the results.
• Refresh tokens the way the client does, so expiry problems show in tests and not in production.

Test data and environments

• Create, don’t borrow. Each run creates the records it needs, with unique names, and removes them at the end.
• Read-only on production. Journeys that only read can run against production; journeys that write belong on test and acceptance.
• One definition, many environments. The same test runs on test, acceptance and production with only the address and accounts changing.
• Mocks for what isn’t there yet. Before a backend exists, a mock built from its contract lets the frontend and the tests start.

In the pipeline and after it

1. Run a small set after every deploy to an environment, and block or flag the release when they fail.

2. Run the important journeys on an interval, so a failure caused by data, configuration or a dependency shows up too.

3. Alert once when a journey starts failing and once when it recovers; an alert on every failed run gets ignored.

4. Keep a history of runs with timings, so you can see when it got slow, not just when it broke.

End-to-end API testing in Journey Lanes

Journey Lanes builds flows from your code and runs them against a mock backend or your live environments. Each environment has an API address, a sign-in type with presets for common identity providers, and a test account per role; writes and load tests stay off until you allow them.

Deploy checks run chosen flows after every deploy from any CI, with a GitHub commit status (CI and exports). Monitoring repeats them on an interval with one alert when they fail and one when they recover (monitoring).