When system integration testing applies versus other test types
Key Takeaway
Integration tests apply when your code interacts with anything not native to your org, such as a third-party service, a billing system, or another Salesforce org.
Integration testing checks that your org works correctly with things outside it, such as a third-party service, a billing system, or another Salesforce org. Other test types, including unit, functional, user acceptance, performance, regression, and end-to-end testing, each answer a different question. To plan a testing effort, you need to know which situation calls for which type.
When integration testing applies
Integration tests apply when you have code that interacts with anything not native to your org. Examples include showing live weather or stock price data from a third-party service on a page layout, and exchanging information with your company's billing systems.
If you have multiple Salesforce orgs, integration testing also covers the interactions between those orgs. Running unit and functional tests inside each org checks each org on its own, which means the interactions between the orgs still need integration tests.
When you integrate with third-party systems, run tests on both sides of the integration, not just the Salesforce side.
Integration testing is not only a final phase. In an agile testing strategy, test execution, including integration testing, happens both alongside development and in iterative cycles.
Priya's manufacturing org uses Apex code to send each confirmed order to a shipping carrier's system. The carrier's system then sends a tracking number back to the order. Her unit tests pass, so each piece of code works on its own. She still needs integration tests, because the code exchanges data with a system that isn't native to her org. Her integration tests confirm that orders arrive at the carrier and that tracking numbers come back to the right orders. She also runs tests on the carrier's side, not just in Salesforce.