Integration Testing
Integration Testing in Salesforce is the practice of verifying that the Salesforce org works correctly with the external systems it talks to: ERP, marketing automation, billing, payment gateways, data warehouses, and any other application connected via API, MuleSoft, ETL, or Salesforce Connect.
Definition
Integration Testing in Salesforce is the practice of verifying that the Salesforce org works correctly with the external systems it talks to: ERP, marketing automation, billing, payment gateways, data warehouses, and any other application connected via API, MuleSoft, ETL, or Salesforce Connect. Integration tests differ from Apex unit tests, which exercise code in isolation with mocked callouts. Integration tests use the actual external endpoints (or contract-tested stand-ins) and confirm that the full data flow works end-to-end across system boundaries.
The discipline is required because Salesforce orgs rarely live alone. A typical enterprise org pushes data to a finance system, pulls leads from a marketing tool, syncs cases with a customer service desk, and exchanges files with a data warehouse. Every release introduces risk that one of these integrations breaks: a deprecated API field, a renamed object, a tightened sharing rule, an unexpected payload change. Integration testing catches these failures before production deploy, typically by running a regression suite against a sandbox connected to a staging copy of every external system.
The integration testing discipline in a Salesforce-centered enterprise
Sandbox connected to staging external systems
The foundation of integration testing is a Salesforce sandbox (Partial Copy or Full Copy) connected to staging instances of every external system the org integrates with. The sandbox receives the new Salesforce release a week before production; testing runs against this combination to surface compatibility breaks before production migrates. Sandbox-staging configuration is the most expensive part of any integration testing program.
End-to-end test scenarios
Integration tests are scenario-based: create a Lead in Salesforce, verify it syncs to the marketing platform; close-won an Opportunity, verify the order lands in the ERP; resolve a Case, verify the status pushes to the CSAT survey tool. Each scenario exercises one or more integrations in the order a real user would. Scenarios are catalogued, prioritized, and run by an automated test runner (Provar, Tricentis, Selenium-based custom suites) or by a manual QA team.
Apex unit tests vs. integration tests
Apex tests are required for deployment (75 percent code coverage) but mock external callouts via HttpMock or Test.setMock. Integration tests pick up where Apex tests leave off, exercising the real external calls. Both layers are necessary: Apex tests verify logic isolated from external dependencies; integration tests verify behavior across systems.
Contract testing as a middle layer
Some teams add contract testing (Pact, Spring Cloud Contract) between unit and integration tests. Contract tests verify that the producer (the external system) returns the response shape the consumer (Salesforce) expects, without actually running the external system. The result is faster, more reliable tests with the contract becoming the source of truth for both sides.
Test data management
Integration tests need test data in both the Salesforce sandbox and the staging external systems, with matching identifiers across both. Most teams maintain a test data refresh process: scripts that seed the sandbox with a known set of records, and corresponding scripts that seed the external systems. Coordinating refreshes across systems is mostly the painful part of integration testing programs.
Salesforce release-driven testing
Salesforce ships three major releases per year. The sandbox typically receives the new release several weeks before production. Integration testing runs against the new release in sandbox; any failures get flagged to Salesforce Support or to the integration team for remediation before production gets the same release. This is the single most important test cycle in any Salesforce-centric enterprise.
Tooling landscape
Provar is the most common Salesforce-specific integration testing tool, offering record-and-playback test creation with strong Lightning UI handling. Selenium and Cypress are general-purpose alternatives. Postman Collections cover API-only integration tests. Tricentis Tosca offers enterprise-grade orchestration. Each tool has tradeoffs; most large orgs use a mix.
Build a basic integration testing program
A first-pass program focuses on the top integrations and the top scenarios. Coverage grows from there.
- Inventory integrations
List every external system Salesforce talks to, the direction of data flow, and the integration mechanism (REST, MuleSoft flow, ETL). Rank by business criticality.
- Identify top scenarios
For each high-priority integration, list the top three or five end-to-end scenarios that must work. Capture as test cases.
- Set up sandbox and staging environments
Provision a Full or Partial Copy sandbox and align it with staging copies of every external system. Configure connections, credentials, and test data.
- Automate the scenarios
Pick a tool (Provar, Selenium, custom) and automate the test cases. Aim for runs against every Salesforce release sandbox.
- Build a test data management process
Scripts or playbooks that seed both Salesforce and the staging external systems with matching test data before each test run.
- Schedule against release cycles
Run the suite when sandbox receives a new Salesforce release. Triage failures with the integration team and Salesforce Support before production migrates.
- Integration tests are expensive to run and maintain. The investment pays off only when the suite catches release-breaking issues before production; under-invested suites become noise.
- Test data drift between Salesforce and external systems is the most common cause of false failures. Plan refresh processes carefully.
- Salesforce release schedules can change. Build automation that reacts to actual sandbox release dates, not assumed ones.
- Apex unit tests are not a substitute for integration tests. Mocked callouts can pass while real integrations fail; the layers complement each other.
Trust & references
Cross-checked against the following references.
- Apex Testing GuideSalesforce Developers
- SandboxesSalesforce Help
Straight from the source - Salesforce's reference material on Integration Testing.
- Mock Callouts in Apex TestsSalesforce Developers
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. What is Integration Testing?
Q2. Why does integration testing matter?
Q3. What's a good complement to integration testing?
Discussion
Loading discussion…