Integration Testing

Why it matters

An interface is where two people’s assumptions meet. When their readings of the agreement differ (riyals or halalas, local time or UTC, a missing field or a null), every component test passes and the defect appears only when the parts run together. A stub rarely reveals it, because it is usually written with the same assumption as the code that calls it.

For the product, integration defects mean wrong charges, lost orders and duplicate messages, often found in production because an external system was only ever simulated. For the tester, this is where reading both sides of an interface pays off.

Component integration and system integration

Integration tests concentrate on the interface: the calls, messages and data passed between parts, and what happens when the other side fails, not the logic inside each component. The test basis is whatever describes the interface: an API specification such as an OpenAPI document, message formats, sequence diagrams.

• Component integration testing: the interfaces between the components of one system, such as the order service calling the inventory component. Usually automated by developers in the continuous integration pipeline.
• System integration testing: the interfaces with other systems and external services, such as a payment gateway or an SMS provider. Usually led by testers; it needs an environment close to production, a sandbox from the other party, and coordination with a team you do not control.

Big-bang or incremental: top-down, bottom-up, stubs and drivers

In big-bang integration, all components are combined at once and tested together. No stand-ins are needed, but testing starts only when every part is ready, and when a test fails the cause can be in any interface. That is acceptable for a very small system; in a larger one, finding the failing interface can take longer than the testing.

Incremental integration adds one component, or a few, at a time and tests each new interface before the next, so a failure points first to the interface just added. Stand-ins, which you met in component testing, replace the missing parts. A stub replaces a called component and returns prepared answers. A driver replaces a calling component: a test script or an API client that calls the component under test as the missing caller would.

• Top-down: start at the top (an API endpoint or the user interface) with stubs for the components below, and replace them one by one. The main flow is visible early; calculations and data access are tested last, and stubs that must return realistic data can grow complex.
• Bottom-up: start with the lowest components (calculations, data access, clients for external services), called by drivers, and work upwards. Foundations are tested early and failures are easy to locate; the complete flow is visible only at the end.
• Many teams combine both and meet in the middle, which is called sandwich or hybrid integration.

Try it: Mock API Response Generator Try it: API Request Builder

Interface defects: what to look for

Interface defects come from two sides that disagree, or from one side that cannot cope when the other fails. A practical first check is to compare each side’s actual requests and responses with the agreed specification, such as the OpenAPI document: a difference shows which side departs from the agreement. Then ask these questions of every interface:

• Format and encoding: is 01/02/2026 the 1st of February or the 2nd of January? Do Arabic names arrive intact?
• Units and meaning: riyals or halalas, seconds or milliseconds, local time or UTC, price with or without VAT.
• Structure: a missing, renamed or extra field; null versus an absent field; enum values that differ (CANCELLED, CANCELED); different length limits on each side.
• Order and timing: calls in the wrong order, a callback that arrives before its record is saved, a timeout shorter than the other side’s normal response time.
• Failure handling: when the other side is down, slow, returns a 500 or an unexpected error body, or answers twice, does the caller retry safely, avoid charging twice and keep the data consistent?

Try it: API Contract Validator Try it: Response Contract Comparator

Worked example: integrating a checkout

A shop’s checkout has five components and calls one external system, as in the plan below. The team integrates bottom-up: the checkout API is written last, and the gateway’s sandbox account is still being arranged, so a stub stands in for the gateway in steps 1 to 3.

The stub was written from the payment client’s own code, so it accepted any amount, and every test in steps 1 to 3 passed. Step 4 runs the same tests against the real sandbox:

• A 150.00 SAR order creates a 1.50 SAR charge: the gateway expects whole halalas, and in JSON 150.00 is simply the number 150. The defect report names the interface (payment-client to gateway), the request and the response.
• Step 4 also covers what only the real system shows: its actual decline codes, its behaviour on timeouts and retries (one charge only), and when its callback arrives.

checkout-api               POST /checkout                          (top)
└── order-service          placeOrder(cart)
    ├── price-calculator   total(cart): SAR, 2 decimals
    ├── inventory          reserve(sku, qty), release(sku, qty)
    └── payment-client     charge(amount, currency)
            └──► payment gateway                        (external system)

Integration order: bottom-up
  1  drivers → price-calculator, inventory, payment-client   gateway: stub
  2  driver → order-service + the components from step 1    gateway: stub
  3  checkout-api replaces the driver                       gateway: stub
  4  the same tests, against the gateway sandbox            system integration

Try it: API Status Code Simulator Try it: Mock Error Response Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018A widely cited explanation of how to balance unit, integration, contract and UI tests in an automated test portfolio.
• Continuous Integration (Martin Fowler)martinfowler.com · 2024The widely referenced description of continuous integration: integrate often, keep the build self-testing and fast, and fix a broken build immediately.