Testing integrations: a practical guide

Most integration bugs are found the same way: a customer calls because their order never arrived, or finance notices that invoices from last Tuesday are missing. The integration “worked” in testing, with one clean sample order, on a quiet afternoon. It just didn’t work with real data, real volumes or a partner system that was down for twenty minutes.

Testing integrations properly is harder than testing a normal application, but it isn’t mysterious. This guide explains why it is hard, the levels of testing that matter, how to deal with test data and external systems, and what is worth automating.

Why integrations are hard to test

You don’t own the systems at either end. The ERP, the e-shop and the courier’s API belong to someone else, may not have a test instance, and may charge per call or send real emails.
Behaviour depends on data. The same flow works for 99 orders and fails for the one with a Greek character in an odd place, a zero-price line or a customer that doesn’t exist yet.
Time and state matter. Incremental syncs depend on “what changed since the last run”. Retries depend on what happened before. A test that passes once may fail the second time.
Failures are partial. Half an order arrives; the stock is updated but the invoice isn’t. These are the hardest bugs and the least tested.
The environments drift. Test and production have different codes, different users and different volumes.

The levels of testing

The familiar testing pyramid applies, with integration-specific meaning at each level.

Unit tests: the logic in isolation

Test one piece of logic with fixed input and expected output, without any external system: a mapping, a calculation, a validation rule. These are fast, cheap and should be the bulk of your tests. Mappings in particular deserve unit tests with real (anonymised) samples, as described in our data mapping guide.

To make unit testing possible, design for it: keep the logic (map, validate, enrich) separate from the connectivity (read from the e-shop, write to the ERP). Logic you can’t run without the ERP is logic you can’t unit test.

Component tests: one flow, with stand-ins

Test a whole flow, with the external systems replaced by mocks or stubs that behave predictably. This is where you test the paths that are hard to provoke for real: the ERP returns an error, the API times out, the partner sends a duplicate.

End-to-end tests: the real chain

Test the full chain in a non-production environment with the real systems’ test instances: place an order in the test e-shop and check it in the test ERP. These tests are slow, fragile and expensive, so keep them few and focused on the most important business scenarios.

Level	What runs	Speed	How many
Unit	One map or rule	Seconds	Many
Component	One flow, external systems mocked	Minutes	One set per flow
End-to-end	Real test instances	Slow	A handful of key scenarios

Test data and masking

Good test data is the single biggest factor in test quality. Build a test data set per interface that includes:

the typical case,
the edge cases you have seen in production (long names, Greek and special characters, zero and negative amounts, credit notes, many lines, no lines),
invalid data that should be rejected.

Production data is the best source of realistic cases, but it contains personal data. Under GDPR, copying customer names, emails, phone numbers and VAT numbers into a test environment needs a reason and protection. The usual answer is masking: replace personal fields with realistic fake values while keeping the structure, lengths and character sets. A masked customer C-1042 should still have a Greek name of the same length, not XXXXX.

Keep test data under version control next to the integration, and treat changes to it like code changes.

Mocking external systems

A mock is a fake version of an external system that returns what you tell it to. Mocks let you:

test without a test instance of the real system,
test error responses (500, timeouts, malformed JSON) on demand,
run tests repeatedly with the same results.

Mocks can be standalone HTTP servers that imitate an API, or simple stand-ins inside the integration platform, such as replacing a connector call with a fixed response in a test version of the flow. Keep mocks honest: they should be based on real recorded responses, and they should be updated when the real system changes. A mock that is more forgiving than the real system gives false confidence.

Contract testing

When two teams or two companies build the two sides of an interface, contract testing checks that both sides agree on the format without running them together. The consumer writes down what it expects (fields, types, status codes), and the provider runs a test that checks it still delivers that. It catches “we renamed a field” before deployment, not after.

Formal contract testing tools are most useful when both sides are developed actively. For a stable third-party API, a simpler version works: keep the API’s schema (OpenAPI, XSD) in version control, validate real responses against it in your tests, and get notified when it changes.

Regression suites

Every integration change risks breaking something that used to work. A regression suite is a fixed set of inputs and expected outputs that you run before every deployment. When a bug is found in production, add the input that caused it to the suite, so it can’t come back.

The suite only works if it runs automatically and if a failure blocks the deployment. A suite that someone has to remember to run will be skipped on the busiest day. Our DevOps for integrations guide covers how this fits into a deployment pipeline.

Testing in non-production environments

Have at least one test environment that mirrors production configuration: same processes, same versions, test credentials and test endpoints.
Point it at test instances, never at production systems “just for one quick test”.
Keep configuration separate from code, so the same tested package is deployed to production with only the configuration changed.
Watch for side effects: emails to real customers, real SMS, real courier bookings, real e-invoices. Disable or redirect them in test.

What to automate

Automate first what is cheap to run and expensive to miss:

Mapping and validation tests with sample data.
Component tests for error paths (target down, invalid data, duplicates).
The regression suite, triggered before every deployment.

Keep manual, exploratory testing for new interfaces and for business acceptance, where a human checks that the result makes sense in the target system.

Common mistakes

Testing only the happy path. Most production incidents come from error paths and unusual data.
One sample document. One order proves the mapping works for one order.
Testing against production. “Just one test order” ends up in the real ERP and in the VAT return.
No expected output. “It ran without errors” is not a test result. Compare against what should come out.
Tests nobody runs. If it’s not automatic and not blocking, it will be skipped.

How to compare tools

What do you need to test? APIs you expose, APIs you call, file and EDI flows, or flows inside an integration platform.
Can it mock what you depend on? HTTP APIs are easy; SOAP, SFTP and databases less so.
Can it run unattended in a pipeline? Command-line runners and machine-readable results matter more than a nice UI.
Who writes the tests? Developers, testers or integration specialists who prefer a graphical tool.
Does it fit your platform? Platform-native testing sees inside the flow; external tools see only inputs and outputs. Most teams need both.

Tools in this space

In alphabetical order.

Boomi Test mode. Built into the Boomi process editor: runs a process on a test runtime and lets you inspect the documents at every shape. Very good for developing and debugging flows. For automated regression testing you combine it with test-harness processes and the Boomi Platform API.
MuleSoft MUnit. The testing framework for MuleSoft Anypoint flows, with mocking of connectors and assertions on results. MuleSoft teams use it for automated unit and component tests inside their build.
Pact. The best-known tool for consumer-driven contract testing, with libraries for many languages and a broker to share contracts. Most useful when both sides of an API are built by teams that can add tests to their code.
Postman. A popular API client that grew into a testing platform: collections of requests with scripted assertions, environments, mock servers, and a command-line runner (Newman / Postman CLI) for pipelines. Easy to start with for REST APIs.
SoapUI / ReadyAPI. SoapUI is the long-standing open-source tool for SOAP and REST testing; ReadyAPI is the commercial suite from SmartBear that adds data-driven testing, virtualisation and reporting. Strong where SOAP and XML are common.
WireMock. An open-source HTTP mock server: record real responses, replay them, and simulate errors and delays. Widely used to stand in for external APIs in component tests.

These tools complement each other rather than compete. A typical setup uses platform-native testing for flow logic, an API tool for the APIs you expose, and a mock server for the systems you call.

Where to go next

Two practical articles show these ideas in Boomi:

Testing Boomi processes during development: Test mode, sample data, inspecting documents per shape and testing error paths.
Regression testing Boomi integrations before deployment: a test-harness pattern and running it from a pipeline.