The test tooling for Payment Hub: the end-to-end suite you run against a deployed stack, and the mock payment scheme those tests (and the Gazelle demo flows) transact against.
| Module | What it is | Ships |
|---|---|---|
integration-test/ |
The end-to-end suite. Cucumber features driven by a JUnit runner, with WireMock standing in for the services it needs to fake. Not a service — you run it against a stack that is already deployed. | a runner image you exec into |
mock-payment-schema/ |
A stand-in payment scheme. A Spring Boot service on port 5000 that answers the calls a real scheme would, so the flows can complete without one. | a Docker image |
mock-payment-schema lives here rather than with the product connectors because it is test tooling:
it mocks a scheme, it does not integrate with one.
These two were separate repositories before (ph-ee-integration-test,
ph-ee-connector-mock-payment-schema).
One Gradle build for the whole repository. Java 21 is required.
./gradlew buildPer module:
./gradlew :mock-payment-schema:bootJarLibrary versions come from the org.mifos:paymenthub-ee-bom platform, published by
paymenthub-ee-core. Do not pin managed versions in
a module's build.gradle.
Both Dockerfiles take the repository root as the build context — the COPY paths are
module-qualified:
./gradlew :mock-payment-schema:bootJar
docker build -f mock-payment-schema/Dockerfile -t paymenthub-ee-mock-payment-schema .docker build -f integration-test/Dockerfile -t paymenthub-ee-integration-test .The suite needs a deployed stack to talk to. Every host it calls is read from
integration-test/src/main/resources/application.yaml
and can be overridden with an environment variable; the defaults are the in-cluster service names.
./gradlew :integration-test:testOne group of scenarios at a time, by Cucumber tag:
./gradlew :integration-test:test -Dcucumber.filter.tags=@commondevis the active development branch — all PRs should targetdev.mainholds released versions.
See contributing.md, our Code of Conduct and the security policy.