Testing EDI pipelines: strategies and tools

EDI chains have long been tested by business layers in pre-production with partners, on month-long cycles. In 2026 we can do better: versioned fixtures, access-point mocks, CI validation, contract testing. This page gathers the strategies that actually work.

Why testing an EDI chain is different

Testing an internal REST API is well-tooled: you write unit tests on controllers, integration tests against a test database, and E2E tests with Playwright or Cypress. Everything is local, reproducible, fast.

Testing an EDI chain adds three difficulties. The partner is external and out of your control — you cannot invoke them in CI without cost and risk. Formats are rigid (EDIFACT D.96A, X12 850, PEPPOL BIS Billing 3.0) and validity is binary: one stray comma fails the whole pipeline. Bugs manifest with delay: a bad mapping triggers a rejection 24h later, not immediately.

Test discipline must therefore compensate for these three properties: lock the partner behind a mock, formalise the format contract in fixtures, and shrink the feedback loop to seconds in CI.

EDI fixtures — the foundation

The bedrock is a directory of fixtures: real (or realistic) EDI messages, versioned in the repo, covering typical cases. Structuring this directory matters. An organisation that works well:

tests/fixtures/edifact/d96a/orders/valid/single-line.edi
tests/fixtures/edifact/d96a/orders/valid/multi-line.edi
tests/fixtures/edifact/d96a/orders/valid/with-charges.edi
tests/fixtures/edifact/d96a/orders/invalid/missing-bgm.edi
tests/fixtures/edifact/d96a/orders/invalid/bad-currency.edi
tests/fixtures/peppol/bis-billing-3/invoice/valid/simple-fr.xml
tests/fixtures/peppol/bis-billing-3/invoice/valid/with-allowances.xml

Each fixture is accompanied by an expected-output file .expected.json (or .expected.txt) describing what the parser or mapper should produce. The test compares actual against expected and fails CI on divergence. This is the direct application of golden file testing to EDI.

Partner mocks

No CI test should call a real external partner. The golden rule. To simulate the partner, you use a mock — a local service that replays expected responses. For typical EDI flows:

• AS2/AS4 mock: a local HTTPS endpoint accepting AS2/AS4 POSTs and returning an expected signed MDN or receipt. Useful 2026 libraries: Open-AS2 (Java), node-as2 (Node.js), or ready-made test Docker images (cef-edelivery-test on the AS4 side).
• SFTP mock: local SFTP server in CI (atmoz/sftp Docker) with a preconfigured directory and expected files.
• PEPPOL access-point mock: for development, either use the OpenPeppol Test Network (a parallel network reserved for tests and certification-in-progress access points) or a local mock access point.

Benefit: tests run in seconds, offline, and are 100% reproducible. Cost: keep mock fidelity in line with the real partner — an obsolete mock can hide a real bug.

PEPPOL access-point sandboxes

Beyond local mocks, most commercial PEPPOL access points expose a sandbox environment in addition to production. The sandbox accepts test submissions, validates them, and simulates delivery to a test recipient without touching the real PEPPOL network. Stedi, Pagero, B2Brouter, Ibanity all offer a public sandbox with a dedicated API key.

Recommended pattern: each environment (dev, staging, prod) configures its own API key + access point pair: dev→local mock, staging→sandbox access point, prod→production access point. Secrets are managed via the cloud platform's secrets manager (AWS Secrets Manager, GCP Secret Manager, Vault).

The PEPPOL Test Network (TEST), operated by OpenPeppol, serves inter-access-point tests. It runs on a test SML and test certificates signed by a PEPPOL test CA. Any submission is flagged and has no legal effect.

Schematron and XSD validation in CI

For UBL/PEPPOL flows, the most powerful test investment is Schematron and XSD validation in CI. On every commit, the GitHub Actions pipeline (or GitLab CI, Jenkins, etc.) validates fixtures against the official OpenPeppol artefacts: PEPPOL-EN16931-UBL.sch, CEN-EN16931-UBL.sch, and the UBL 2.1 XSD.

Practical tool: Saxon HE (free) to execute Schematron via XSLT, plus xmlstarlet or xmllint for the XSD. The whole wrapped in a bash script executed in CI. When OpenPeppol publishes a new Schematron version (typically twice a year), update the pipeline and rerun CI; fixtures that no longer pass become cases to fix.

For EDIFACT flows, the ediverse validator — the EDIFACT Validator page — is integrable into CI through its REST API. You submit a message, retrieve the error list, and check that it is empty for valid fixtures and contains the expected error for invalid fixtures.

Contract testing the mappings

The contract testing pattern brings to EDI what Pact brought to microservices: pin a contract between two endpoints, and test the endpoint in isolation. For an EDIFACT→ERP-internal-JSON mapping, the contract is a spec file stating: "this BGM segment with qualifier 220 must yield the orderNumber field in the JSON".

Typical implementation: a parameterised test suite. For each case, provide the input fixture (EDIFACT) and the expected output JSON. The test runs the mapper and compares. This suite runs in seconds and guarantees a mapping regression is caught before production.

For bidirectional mappings — EDIFACT ↔ JSON, UBL ↔ Factur-X, or HL7 v2 ↔ FHIR — you test both directions: a round-trip must be idempotent up to known conventions (date encoding, separators). That property, the round-trip property test, catches a class of bugs invisible otherwise.

End-to-end tests and environments

At the top of the pyramid, E2E tests cover the full chain: generation from the ERP, local validation, submission to the sandbox access point, acknowledgment reception, reading by the test recipient. These tests are slow (minutes to hours) and fragile (depend on external environments), so reserve them for staging smoke tests after each deployment, not every PR.

Environments to organise:

• dev: 100% local, mocks, no external network. Unit tests + contract tests + Schematron CI. <1 min.
• staging: sandbox access points, fictitious test partners. Daily smoke E2E tests, triggered by each staging deployment. <15 min.
• prod: real partners, real amounts, real VAT. No automated test writes to prod without prior coordination with the partner.

Further reading

• EDIFACT Validator — usable in CI through its REST API.
• PEPPOL Validator — for UBL/EN 16931 flows.
• Patterns catalogue — Dead Letter Channel, Circuit Breaker and their test equivalents.
• EDI patterns in 2026 — the long-form article on testable patterns.