Image eventually created by OpenAI GPT-5.5 after
about 5 prompts by Bob Buzzard
Introduction
A feature that seems to have flown under the radar in the Summer '26 release
of Salesforce is the new Apex Integration Testing capability. For the first
time integration testing (albeit quite limited) is a first-class discipline on
the platform. With a bit of luck this foreshadows an end to our reliance
on external tooling and
Heath Robinson (or
Rube Goldberg
for our friends across the pond) combinations of unit tests and mocks
masquerading as integration tests.
Before we get too excited it's worth bearing in mind that this is currently in
Developer Preview for scratch orgs only, and is limited to interactions with
the Data 360 and Agentforce Salesforce services, but hopefully this will be
relaxed in the future and we'll be able to make callouts to any authorised
endpoint that we choose.
Integration Tests
If you haven't come across integration testing before, you can think of it as
the next programmatic testing step after unit testing. Unit tests check
whether a piece of code works in total isolation, while integration tests
check that the various unit tested pieces still work correctly when they are
connected to each other.
An Apex class/method becomes an integration test through the simple
application of the
@IntegrationTest annotation where a
unit test would have the
@IsTest annotation. Aside from
that, they start out rather similar to Apex unit tests:
- Set up data
- Execute code under test
- Verify results.
Where they diverge (but align with just about every other unit test framework
in the world) is tearing down the changes made. In Salesforce world we've
never had to care about that before, as the Apex unit test framework rolls
back any changes we've made automatically. Integration tests commit changes to
the Salesforce database, so there's clearly a need to reset the database to a
known, stable state.
Teardown methods are identified through the
@TearDown annotation, are executed
after every test regardless of success or failure, and commit automatically.
You can also have more than one of them in a class, in which case they will
all execute after every test and you can't specify the order that they execute
in.
It's also really important to bear in mind that just because teardown methods
run after every test, they won't necessarily complete successfully. They can
error, just like any other piece of code. If they do error, the test will be
marked as a failure, as well as the database being left in an indeterminate
state. For this reason, defensive code is a must for teardown methods.
Executing Integration Tests
As integration testing is in developer preview, it can only be used in scratch
orgs at present. Enable integration testing through the
ApexIntegrationTests feature:
Once you have created a scratch org with this configuration, you can deploy
integration test classes to it. You can execute integration test classes like
unit test classes, through setup, the developer console or the Salesforce CLI,
although remember they have to run asynchronously.
You can only have a single integration test running in an org at any point in
time. This isn't an issue in a scratch org, but could be entertaining in
sandboxes - everyone gets a couple of hours a week to run tests in peace
maybe? Although I'm sure that restriction will be loosened as the
functionality approaches GA.
Apex governor limits apply to integration tests, which probably restricts how
useful they will actually be. This is another aspect I wouldn't be surprised
to see loosened over time, they are running asynchronously after all, but it's
unlikely we'll get to parity with external tools that can span multiple
transactions.
More Information
