Introduction

pipelite-test-support lets you test the two building blocks of a Pipelite application — a single processor and a full flow — using the same fluent, given/when/then chain. No running container, no real endpoints, no manual Exchange plumbing.

Maven dependency

Add pipelite-test-support to your project in test scope:

<dependency>
    <groupId>io.pipelite</groupId>
    <artifactId>pipelite-test-support</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <scope>test</scope>
</dependency>

Single import

All factory methods used by the fixture are aggregated in one class, PipeliteTest. A single static import is enough for an entire test class — no need to import Preconditions, Actions, or Expectations individually:

import static io.pipelite.test.PipeliteTest.*;

The BDD chain

Every test — whatever it verifies — follows the same three phases:

given(Precondition...)  ─►  when(Action)  ─►  then(Expectation...)

given(…) describes the starting state: headers, input payload, which flows (if any) are involved, and an optional timeout.
when(…) activates the component under test: either a bare Processor or a running flow.
then(…) verifies the outcome, and can also be used to pull the resulting payload or headers out directly for use with your own assertion library.

given(
        header("Source-System", "Legacy-API"),
        inputPayload(Map.of("price", 100)))
    .when(process(myProcessor))
    .then(isSuccess(), payloadEquals(Map.of("price", 110)));

Two testing modes, one API

What differs between test styles is only what you pass to when(…):

Mode	Use it to
Processor testing	Unit-test one processing step in isolation, synchronously, with no engine involved.
Flow testing	Exercise a complete pipeline — one or more linked flows — from source to sink, including intermediate steps.

Mode

Use it to

Processor testing

Unit-test one processing step in isolation, synchronously, with no engine involved.

Flow testing

Exercise a complete pipeline — one or more linked flows — from source to sink, including intermediate steps.

The Expectation`s available in `then(…) depend on which mode produced the result (see the Appendix for the full breakdown), but the shape of the test — given → when → then — never changes.