Chain testing: does the process work across every system it touches?

What chain testing is

Most processes run through more than one system: an order goes from the web shop to an order service, a payment provider, a warehouse system and an invoicing service. Each of those is tested by its own team. A chain test checks the chain: one order, put in at the start, tracked to the end, with every hand-over checked on the way.

The term is common in the Netherlands and Belgium (ketentest, ketentesten), often in government and enterprise projects where systems of several suppliers have to work together. Elsewhere the same thing is called end-to-end testing across systems, or system integration testing at the level of a business process.

Scoping a chain test

1. Pick the process, not the systems: “a customer orders, pays and gets an invoice”, not “test the invoice service”.

2. Draw the chain: which systems, in which order, and what each hands to the next (an id, a message, a file, an email).

3. Decide where you observe each hand-over: an API you can read, a status you can poll, an email in a test inbox.

4. Agree which environment the chain runs in, and that every system in it is a version that belongs together.

5. Write down the end state that proves the chain worked, and the states that prove it broke (stuck in pending, a missing invoice).

What makes chain tests hard

• Test data across systems. The customer has to exist in every system involved. Let the chain create its own data at the start, with unique names, instead of relying on records that someone set up once.
• Asynchronous steps. Hand-overs often go through a queue, a batch or a webhook. Poll a read until the expected state appears, with a time limit, instead of waiting a fixed time.
• Access between systems. Each system has its own sign-in. A chain test needs a test account per system and per role, kept outside the test code.
• Environments that drift. One system on a newer version breaks the chain for everyone. Running the chain after each deploy shows which change broke it.
• Ownership. When a chain test fails, every team assumes it’s another team’s system. Make the failing step and its answer visible to everyone.

Automating chain tests

Manual chain tests are typically run before a big release, take days, and are out of date by the next one. Automated, they become a check that runs after each deploy and on a schedule. What you need for that:

• Each system reachable over an API from where the tests run, or through an agent inside the network.
• One place that knows every system’s address per environment, so the same chain runs on test and on acceptance.
• Steps that pass values from one system’s answer into the next system’s call.
• Clear output: which step in which system failed, with the answer it got.

Chain testing in Journey Lanes

A Journey Lanes project can hold a repository per service. On an environment, each service gets its own address, and a step goes to the service whose code defines its endpoint, so one flow runs through every service in the chain. Steps pass values on with {{step-id.path}}, reads can repeat until the next system shows the result, and email steps read what a system sent from a test inbox (live environments).

In this example one role creates the records another role then works with, so the flow checks the hand-over between them:

Systems on a private network are reached through a relay agent you run inside it. Two environments can be compared step by step (checks), and the chain can run after every deploy and on an interval. Journey Lanes calls HTTP and gRPC APIs: a system with no API to call or read has to be observed through one that does.