Journey Lanes

Cases

The frontend team waits for an API that isn’t deployed yet

The endpoints exist in a branch, but there’s no server to call, and the hand-written mock is already out of date.

  • Employee

Why ordinary tests miss it

Hand-written mocks drift from the real API, and shared test environments are busy, broken or a deploy behind. The frontend ends up built against guesses.

Set it up

  1. Connect the repository, on the branch with the new endpoints. Journey Lanes builds a mock backend from what it scans: the records, scoped per company, and a Keycloak-style token endpoint.

  2. Point the frontend at the mock’s address and sign in with its token endpoint, as you would with Keycloak.

  3. When a flow needs a known starting point, give it its own mock data and start fresh before every run.

  4. Scan again when the branch changes. The mock follows the code.

The moment it’s caught

What the frontend gets from the mock
  1. ✓ EmployeePOST /realms/portal/protocol/openid-connect/token 200, a token with the employee’s roles
  2. ✓ EmployeeGET /api/products 200, products in the shape the code declares
  3. ✓ EmployeePOST /api/orders 201, the new order, in the employee’s company
  4. ✓ EmployeeGET /api/orders 200, only the orders of the employee’s company
An example of what you see, in Journey Lanes’ own words. The numbers and names are made up.

The frontend works against the API as the code defines it, with data scoped per company, before the API is deployed anywhere.

What you use

Next case: An order fails somewhere across three services

Catch this one in your own product

Connect a repository, describe the journey, and run it against the mock in a few minutes.

Log in See how it works