Integration and System Testing

Analogy categoryAnalogies

Introduction

Unit tests verify one component at a time, but real applications are made of many components working together — services, databases, message queues, and external APIs. Integration testing and system testing exist to catch the bugs that only appear when those pieces interact.

🏏

Cricket analogy: Testing a bowler's individual delivery accuracy in the nets is like a unit test, but it can't reveal how they'll perform against a real batting partnership under match pressure with fielders and a scoreboard in play.

Explanation

Integration testing verifies that two or more components work correctly together, such as a service layer talking to a real (or test) database, or two microservices communicating over HTTP. Unlike a unit test, an integration test does not isolate the component from its collaborators; instead it deliberately exercises the boundary between them, catching problems like incorrect SQL queries, serialization mismatches, or misconfigured API contracts that unit tests — which typically mock those collaborators — would miss.

🏏

Cricket analogy: Checking that a bowler's yorker actually gets a batsman out in a real practice match against the middle order is an integration test, deliberately exercising the bowler-batsman boundary rather than isolating the bowler's technique alone.

System testing goes a level further: it validates the entire application as a complete, integrated whole, typically through the same interfaces a real user or external client would use, such as HTTP endpoints or a browser UI. System tests (sometimes called end-to-end tests) exercise the full deployed stack — frontend, backend, database, and any third-party integrations — to confirm that the system as a whole meets its requirements. To summarize the three levels: unit testing isolates a single component with all dependencies replaced or removed; integration testing checks a small group of real components interacting; system testing checks the entire application end-to-end.

🏏

Cricket analogy: A full day-night pink-ball Test match, played start to finish with real umpires, real crowds, and real broadcast feeds, is system testing: unit tests check a single delivery, integration tests check bowler-batsman interaction, and the full match checks everything end to end.

Example

python

# Integration test: the OrderService talking to a real test database.
# Unlike a unit test, we do NOT mock the database here — we want to
# verify the actual SQL and data mapping work correctly together.
import pytest


def test_order_service_persists_order_to_database(test_db_session):
    # Arrange: a real (test) database session is provided by a fixture
    service = OrderService(db_session=test_db_session)

    # Act
    order_id = service.create_order(customer_id=42, items=["sku-1", "sku-2"])

    # Assert: read back from the same real database to confirm persistence
    saved_order = test_db_session.query(Order).get(order_id)
    assert saved_order.customer_id == 42
    assert len(saved_order.items) == 2


# System test: exercising the whole application through its public HTTP API,
# the same way a real client would.
def test_checkout_flow_end_to_end(http_client):
    # Arrange
    payload = {"customer_id": 42, "items": ["sku-1", "sku-2"]}

    # Act
    response = http_client.post("/api/orders", json=payload)

    # Assert
    assert response.status_code == 201
    assert response.json()["status"] == "confirmed"

Analysis

The integration test uses a real test database session rather than a mock, so it can catch bugs that only appear when the ORM mapping and actual SQL execute together — something a unit test with a mocked database would never detect. The system test goes further still: it sends an HTTP request to the running application's public API and checks the full response, exercising routing, validation, business logic, and persistence together, just as a real client would experience it. Notice the tradeoff: the system test tells you the least about where a failure occurred (it could be anywhere in the stack), but it gives the strongest guarantee that the feature actually works for real users, which is why the pyramid keeps these tests few in number and reserves them for critical user journeys.

🏏

Cricket analogy: A real intra-squad match with real fielders catches issues a solo net session with a bowling machine never would, but a full televised international match reveals the truest test of form under real pressure, which is why boards schedule few such series and reserve them for crucial fixtures.

Key Takeaways

Unit testing isolates a single component and replaces its dependencies.
Integration testing verifies real interaction between two or more components, such as a service and a database.
System testing validates the entire deployed application end-to-end through its real interfaces.
Integration and system tests catch bugs at component boundaries that unit tests, which mock collaborators, cannot.
System tests give the strongest confidence but are the slowest and hardest to debug when they fail.

Practice what you learned

1. What distinguishes integration testing from unit testing?

2. System testing is best described as:

3. In the integration test example, why is a real test database used instead of a mock?

4. Which statement correctly orders the scope of the three testing levels from narrowest to broadest?

Was this page helpful?

Unit Testing

Test-Driven Development

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Microservices Study Notes

Software Architecture · 30 topics

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Git & Version Control Study Notes

Bash · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#Python#SoftwareEngineeringStudyNotes#SoftwareEngineering#IntegrationAndSystemTesting#Integration#System#Testing#Explanation#StudyNotes#SkillVeris

Introduction

Explanation

Example

Analysis

Key Takeaways

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in Software Engineering

Topics covered