Integration Testing
Integration testing in Salesforce is the practice of verifying that an org works correctly with the external systems it talks to, such as an ERP, a marketing platform, a billing engine, a payment gateway, or a data warehouse.
Definition
Integration testing in Salesforce is the practice of verifying that an org works correctly with the external systems it talks to, such as an ERP, a marketing platform, a billing engine, a payment gateway, or a data warehouse. These systems connect through REST or SOAP APIs, MuleSoft, ETL jobs, or Salesforce Connect. An integration test exercises the real data flow across those boundaries, confirming that a change on one side does not silently break the other.
Integration testing sits one layer above Apex unit tests. Unit tests run in isolation and replace every external HTTP callout with a mock, so they never touch the outside world. Integration tests do the opposite. They run against live staging endpoints, or contract-tested stand-ins, and confirm that records, payloads, and identifiers move end to end the way a real user would expect.
How integration testing fits a Salesforce release cycle
Why an isolated org is not enough
A production Salesforce org almost never lives alone. It pushes closed-won orders to a finance system, pulls leads from a marketing tool, syncs cases with a support desk, and exchanges files with a warehouse nightly. Every one of those connections is a contract between two systems that were built and released on different schedules. Apex unit tests, required for deployment at seventy-five percent code coverage, deliberately ignore those contracts. They mock callouts so the code under test runs fast and deterministically, with no network dependency. That isolation is correct for unit testing, but it leaves a real gap. A unit test will happily pass while the marketing platform has renamed a field, tightened an auth scope, or changed a JSON payload shape. Integration testing exists to close that gap. It treats the boundary itself as the thing under test, asking a simpler question than any unit test can: when Salesforce actually calls the other system, does the right data arrive, and does the response come back in the shape the org expects? That question only has an honest answer when a real call crosses the wire.
Sandboxes wired to staging systems
The standard setup is a Salesforce sandbox connected to staging copies of every external system in scope. Salesforce documents four sandbox types, and the choice matters for this work. Developer and Developer Pro sandboxes copy configuration only, with no production records, and Developer Pro is sized for quality assurance and integration testing. A Partial Copy sandbox adds a sample of production data driven by a sandbox template, and Salesforce recommends it for user acceptance testing, integration testing, and training. A Full sandbox replicates the entire dataset and is recommended for performance testing, load testing, and staging, though its long refresh interval makes it awkward for day-to-day development. Most enterprise programs run integration suites in a Partial Copy or Full sandbox so that record volumes and relationships resemble production. The matching staging instances of the ERP, the marketing tool, and the rest are pointed at that sandbox through named credentials, so endpoints and secrets are managed in one place rather than hardcoded across classes.
Scenario-based tests across boundaries
Integration tests are written as scenarios that mirror real business events. Create a Lead in Salesforce and confirm it appears in the marketing platform. Close-won an Opportunity and confirm an order lands in the ERP with the correct totals. Resolve a Case and confirm the status pushes to the survey tool. Each scenario walks one or more integrations in the order a user would trigger them, then asserts on the end state in both systems. Teams catalogue these scenarios, rank them by business impact, and run the high-value ones on every release. Some flows are synchronous request and reply over REST or SOAP. Others are event-driven, where a Platform Event or a Change Data Capture message fires and a subscriber on the far side reacts. Event-driven flows need tests that wait for asynchronous delivery rather than checking immediately, since the far system processes the message on its own clock. Getting the assertions and the timing right is most of the craft here.
Where Apex mock callouts stop and integration starts
It helps to be precise about the unit-test layer, because the two are often confused. Apex test methods do not support real HTTP callouts. By default a test that performs a callout fails, so the platform requires you to supply a fake response. You implement the HttpCalloutMock interface, returning a synthetic HttpResponse from its respond method, then register it with Test.setMock before the callout runs. After that call, the platform intercepts the request and hands back your fake response instead of hitting the network. StaticResourceCalloutMock and MultiStaticResourceCalloutMock let you store canned responses as static resources for cleaner tests. All of this is excellent for proving your parsing, error handling, and DML logic in isolation. None of it proves the other system still behaves. That is the dividing line. Mocked Apex tests verify your code given an assumed response. Integration tests verify the assumption itself, by calling the real staging endpoint and checking what actually comes back. A healthy program keeps both, because each catches a class of defect the other cannot see.
Contract testing as a middle layer
Between fast mocked unit tests and slow full integration runs, many teams add contract testing with tools like Pact. A contract test pins down the exact request and response shape that a consumer and a provider agree on. Salesforce, as the consumer, records the responses it depends on, and the external system, as the provider, verifies it can still produce them. Neither side has to spin up the other at test time, so the tests stay fast and stable while still guarding the boundary. The agreed contract becomes a shared source of truth, and a breaking change shows up as a failed contract verification rather than a mysterious production incident weeks later. This layer is especially valuable when the external system is owned by a different team or vendor on a separate release cadence. It does not replace end-to-end integration tests, which still catch network, auth, and environment issues that a contract cannot model, but it shrinks how often the expensive end-to-end suite has to find a basic shape mismatch.
Test data that lines up on both sides
The quiet failure mode of integration testing is data drift. A scenario needs a matching record on each side, with identifiers that line up, or the test fails for reasons that have nothing to do with the integration. So teams build a refresh process: scripts that seed the Salesforce sandbox with a known set of records, and matching scripts that seed the staging external systems with the same keys. When a Partial Copy or Full sandbox is refreshed from production, those seeds usually have to be reapplied, and the external staging systems have to be re-synced to stay aligned. Coordinating that refresh across several systems is the most operationally painful part of most integration programs, and it is the most common source of false failures. Treat the seed data as code, version it alongside the test suite, and refresh both sides together. Stable, predictable test data is what lets a red result mean a real regression instead of a setup mistake.
Driving the suite from the release calendar
Salesforce ships three major releases a year, and sandboxes on a preview instance are upgraded several weeks before production, commonly four to five weeks ahead. That preview window is the single highest-value test cycle in a Salesforce-centric enterprise. You point the integration suite at a preview sandbox running the next release, wired to your staging systems, and you find out what the upgrade breaks while there is still time to act. Anything that fails gets routed to the integration team or raised with Salesforce Support before the same release reaches production. To make this repeatable, schedule the suite to run automatically on each sandbox refresh and preview upgrade rather than relying on manual kickoffs, which lose track of which build was tested when. Common runners include Provar, which is Salesforce-aware and supports record and playback against the Lightning UI, alongside general-purpose options like Selenium and Cypress for the UI and Postman collections for API-only checks. Most large orgs run a mix rather than betting on one tool.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Integration Testing.
Hands-on resources to go deeper on Integration Testing.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. How does Integration Testing differ from an Apex unit test when verifying a callout?
Q2. Why does integration testing catch bugs that pass cleanly in Apex unit tests?
Q3. Why do enterprises run integration tests against a sandbox before each Salesforce release?
Discussion
Loading discussion…