Your recommended stack

2 areas to cover, based on what you told us

“Test data and environments are a mess”

1. Test Data, Mocking & Service Virtualisation

Because you said: “Test data and environments are a mess”

WireMockBest fitFree tier

The standard HTTP mock server for JVM and beyond: record, replay, stub, simulate faults.

Why this fits you

Fault and latency injection lets you test the error paths that never occur on demand in a real sandbox.
Record-and-replay produces a realistic mock from live traffic quickly.

Main limitation

Recorded stubs drift from the real service unless you re-record or verify contracts.
Complex stateful scenarios get verbose in JSON.

Intercept requests at the network layer so your app code never knows it is mocked.

Why this fits you

One set of handlers reused across unit, component, E2E and local development.
Application code is completely unaware it is being mocked — no test-only branches.

Main limitation

Real databases and services in throwaway Docker containers, per test run.

Why this fits you

Tests run against the real database engine, so dialect and behaviour differences surface early.
Containers are disposable, which removes shared-state flakiness entirely.

Main limitation

Because you said: “Test data and environments are a mess”

PostmanBest fitfrom $14Free tier

The API platform most developers already have open: requests, collections, tests, mocks.

Why this fits you

Main limitation

Cloud-first sync raised real concerns for teams handling sensitive API credentials; the offline story has been repeatedly reduced.
Collections stored in the vendor cloud rather than your repo make code review and branching awkward.

Brunofrom $19Free tier

Git-native API client that stores collections as plain files in your repo.

Why this fits you

Main limitation

No built-in mock servers or monitoring; it is a client and runner, not a platform.
Younger project with a smaller ecosystem and fewer integrations.