Regression testing Boomi integrations before deployment

You change one line in the order mapping to support a new payment method. It works. Two weeks later finance finds that credit notes have been arriving in the ERP with the wrong sign since that change. Nobody tested credit notes, because nobody changed anything about credit notes.

This is what regression testing is for: re-checking everything that used to work, every time something changes. This article explains the pattern in general terms, then builds it for Boomi processes.

Why manual retesting doesn’t scale

After a change, most teams retest the case they changed and maybe one or two others. That’s natural, and it misses exactly the bugs above: side effects in cases nobody thought were affected. Full manual retesting of every case is too slow to do before every deployment, so it doesn’t happen.

The answer is a test suite that:

runs the same fixed inputs every time,
compares the results with expected outputs automatically,
runs without a person, so it can run before every deployment,
blocks the deployment when something differs.

The pattern: a test harness

A test harness is a separate flow whose only job is to run test cases against the logic you want to protect.

For each test case:
  input document  ──► logic under test ──► actual output
  expected output ─────────────────────────► compare ──► pass / fail
Summary: N passed, M failed  ──► overall status (success / error)

Three design decisions make this work:

Test the logic, not the connectors. The harness calls the mapping, validation and enrichment logic directly with stored inputs. It doesn’t read from the real e-shop or write to the real ERP. That keeps it fast, repeatable and free of side effects. Connectors are covered by a small number of end-to-end tests.
Normalise before comparing. Outputs often contain values that change on every run: timestamps, generated IDs, execution IDs. Remove or fix them before the comparison, or every test will fail.
Make failure visible to machines. The harness must end in a clear failed state when any case fails, so a pipeline can stop the deployment.

Building it in Boomi

There isn’t a single built-in “regression suite” button for Boomi processes, so this is a pattern you build from standard components. The pieces below are deliberately simple; adapt them to your conventions.

Step 1: Make the logic callable

If you followed Testing Boomi processes during development, the business logic already lives in a subprocess that ends with a Return Documents shape:

Order sync (deployed):   e-shop connector ──► Process Call "Order logic" ──► ERP connector
Order logic (subprocess): Map ──► validations ──► lookups ──► Return Documents

If not, this is the first refactoring to do. A harness can only test what it can call without the real systems.

Step 2: Store test cases

For each case keep two files with matching names, for example:

regression/order-logic/
  001-standard-order.input.json
  001-standard-order.expected.xml
  002-credit-note.input.json
  002-credit-note.expected.xml
  003-greek-long-address.input.json
  003-greek-long-address.expected.xml
  004-unknown-payment.input.json
  004-unknown-payment.expected.xml   (expected: rejected, with this error message)

Keep the folder in version control with the rest of your integration assets. Generate the first expected outputs by running the current, trusted version and checking each result by hand once. Every bug found in production becomes a new numbered case.

How the harness reads the files depends on your runtime. On a local Atom or Molecule, the Disk connector can read them from a folder that your pipeline keeps in sync with the repository. On a cloud runtime without a shared folder, you can embed the cases in Message shapes in the harness, or fetch them from a repository or storage service with an HTTP call.

Step 3: Build the harness process

A straightforward structure:

Read the inputs (Disk Get, or Message shapes), keeping the case name in a dynamic document property.
Read the matching expected output for each case and keep it in another dynamic document property, or load the expected files into a document cache keyed by case name.
Process Call to the logic subprocess, the same component the real process uses.
Normalise the actual output: remove timestamps and generated IDs, for example with a small map or a script step.
Compare actual with expected. For exact comparisons, a Data Process shape with a short custom script is usually the simplest option; it can also produce a readable difference. For a few key fields, a Decision shape comparing properties is enough.
Record the result per case with a Notify shape (PASS 002-credit-note or FAIL 002-credit-note: Amount expected -24.80, got 24.80).
Fail the run if any case failed: route failures to an Exception shape after all cases are processed, so the execution ends with an error status.

The detail of step 5 is the part that varies most between teams. Keep the comparison strict for fields that matter (amounts, codes, quantities, dates) and decide explicitly what you ignore.

Step 4: Run it against a test environment

Deploy the harness to your test environment only, never to production. It should be deployed together with the version of the logic subprocess you want to test, using the same packaged components you plan to promote.

Run it from the process editor in Test mode while you build it. Once it works, deploy it and run it as a normal execution, so it can be triggered remotely.

Step 5: Trigger it from a pipeline

The Boomi Platform API (formerly the AtomSphere API) lets external tools manage deployments and start processes. A pipeline step can:

Deploy the new package to the test environment.
Start the harness process on the test runtime.
Wait for the execution to finish and read its status.
Stop the pipeline if the status is an error; otherwise continue towards production.

Starting a process is done with an execution request. In outline, it looks like this; check the current API reference for the exact endpoint, payload and authentication options for your account:

# Outline only: confirm details against the Boomi Platform API reference
curl -s -u "BOOMI_TOKEN.ci-user@example.gr:$BOOMI_API_TOKEN" \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -X POST "https://api.boomi.com/api/rest/v1/$ACCOUNT_ID/ExecutionRequest" \
  -d '{
        "@type": "ExecutionRequest",
        "atomId": "'"$TEST_ATOM_ID"'",
        "processId": "'"$HARNESS_PROCESS_ID"'"
      }'

The response identifies the request. The pipeline then polls the execution record until it reaches a final status and treats an error status as a failed test run. Use a dedicated API user with only the permissions the pipeline needs, and store the token in the pipeline’s secret store, never in the script.

How this fits into packaging and promotion between environments is covered in Packaged deployments in Boomi.

Before you go live

Start small. Ten good cases covering the main document types and the known edge cases are worth more than a hundred copies of the same order.
Keep expected outputs reviewed. When a change is intentional, update the expected files in the same change and have someone review the difference.
Never point the harness at production systems. It tests logic. If it ever needs a connector, use test instances or mocks.
Watch the run time. If the suite gets slow, people will want to skip it. Split it per flow and run what changed.
Mask your test data. Cases taken from production must not carry real personal data.

Summary

Regression testing protects everything you didn’t mean to change. For integrations, the pattern is a harness that feeds fixed inputs to the logic, compares results to expected outputs and fails clearly. In Boomi you build it from standard parts: a callable logic subprocess, stored cases, a harness process, a test environment and the Platform API to trigger it from a pipeline. For the wider picture, see our testing integrations guide.