System integration testing (SIT)
System integration testing, usually shortened to SIT, verifies that separately developed components work correctly together once assembled. It targets the interfaces between modules and systems, which is where units that each pass their own tests still fail as a whole. It runs with the real components in place rather than with mocks.
The longer version
Unit tests verify a component against its own contract, and a component can honour that contract while still being unusable by the thing that calls it. The mismatches live at the boundaries: a date sent as a string and read as a timestamp, a field that is optional on one side and required on the other, a call that succeeds but returns before the write it triggered has landed.
SIT is the stage that exercises those boundaries with the real components in place rather than with mocks. That distinction is the point. A mock encodes what you believe the other system does, so a suite built entirely on mocks verifies your beliefs rather than the integration. SIT replaces the mocks with the actual services, including the third-party ones where that is possible.
It usually runs after component-level testing and before user acceptance testing, on an environment where all the pieces are deployed together. In systems assembled from many services, it is often the longest and least predictable stage, because a failure can come from any of the participants or from the network between them.
The distinction from UAT is worth keeping clear, because both sit near the end. SIT is technical and run by the team, asking whether the assembled system works. UAT is run by users, asking whether the working system is the right one.
Common questions
What is the difference between SIT and UAT?
SIT is a technical check that separately built components work together, performed by the team. UAT is a business check that the assembled system meets the need, performed by users. SIT normally runs first: there is little point asking users to accept a system whose parts do not yet talk to each other.
What does SIT stand for in testing?
System integration testing. It is the stage that verifies interfaces between components and between systems after each has been tested on its own.
Why not use mocks for integration testing?
A mock encodes what you believe another system does, so a suite built on mocks confirms your beliefs rather than the integration. Mocks are useful for isolating a unit; integration testing exists specifically to replace them with the real components and find the mismatches.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.