Integration testing in Microservices - System Design Exercise

Design: Microservices Integration Testing System

Design the integration testing system architecture for microservices. Exclude unit testing frameworks and production deployment strategies.

Functional Requirements

FR1: Test interactions between multiple microservices to ensure they work together correctly

FR2: Support automated test execution for continuous integration pipelines

FR3: Simulate real service dependencies and communication (e.g., REST, messaging)

FR4: Provide clear test result reporting and error tracing

FR5: Allow testing of both synchronous and asynchronous communication patterns

Non-Functional Requirements

NFR1: Handle up to 50 microservices in the system

NFR2: Test execution time should be under 10 minutes for a full integration suite

NFR3: Test environment must isolate from production data and services

NFR4: Availability of test infrastructure should be 99.9%

NFR5: Latency of test orchestration commands should be under 1 second

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Test Orchestrator to run and coordinate tests

Service Stubs or Mocks for unavailable dependencies

Test Environment Manager for setup and teardown

Logging and Monitoring tools for test execution

Test Result Aggregator and Reporter

Design Patterns

Consumer-Driven Contract Testing

Test Doubles (Mocks, Stubs, Fakes)

Service Virtualization

Event-driven Testing for asynchronous flows

Blue-Green or Canary deployment for test environments

Reference Architecture

                    +---------------------+
                    |  Test Orchestrator   |
                    +----------+----------+
                               |
          +--------------------+--------------------+
          |                                         |
+---------v---------+                     +---------v---------+
| Service Stubs/    |                     | Test Environment  |
| Mocks             |                     | Manager           |
+---------+---------+                     +---------+---------+
          |                                         |
+---------v---------+                     +---------v---------+
| Microservices      |<------------------->| Logging &         |
| Under Test         |                     | Monitoring        |
+--------------------+                     +-------------------+
                               |
                    +----------v----------+
                    | Test Result Aggregator|
                    +---------------------+

Components

Test Orchestrator

Custom or open-source test runner (e.g., Jenkins, GitHub Actions)

Coordinates execution of integration tests across microservices

Service Stubs/Mocks

WireMock, MockServer, or custom mocks

Simulate dependent microservices or external APIs to isolate tests

Test Environment Manager

Docker Compose, Kubernetes namespaces, or Terraform

Provision and isolate test environments with required services and data

Logging & Monitoring

ELK stack (Elasticsearch, Logstash, Kibana), Prometheus, Grafana

Collect logs and metrics during tests for debugging and analysis

Test Result Aggregator

JUnit reports, Allure, or custom dashboards

Aggregate test outcomes and provide clear reports to developers

Request Flow

1. 1. Developer or CI pipeline triggers the Test Orchestrator to start integration tests.

2. 2. Test Orchestrator requests the Test Environment Manager to provision isolated test environment.

3. 3. Test Environment Manager sets up microservices under test and any required stubs/mocks.

4. 4. Test Orchestrator runs test scripts that invoke microservices endpoints or send messages.

5. 5. Microservices communicate with each other or with stubs/mocks as per test scenarios.

6. 6. Logging & Monitoring collects logs and metrics during test execution.

7. 7. Test Orchestrator collects test results and sends them to Test Result Aggregator.

8. 8. Test Result Aggregator compiles reports and notifies developers of pass/fail status.

9. 9. Test Environment Manager tears down the test environment after tests complete.

Database Schema

Entities: - TestRun: id, start_time, end_time, status, environment_id - Environment: id, configuration_details, status - MicroserviceInstance: id, service_name, version, environment_id - TestCase: id, name, description, test_run_id, status, error_message - LogEntry: id, timestamp, microservice_instance_id, log_level, message Relationships: - One Environment has many MicroserviceInstances - One TestRun runs in one Environment - One TestRun has many TestCases - One MicroserviceInstance has many LogEntries

Scaling Discussion

Bottlenecks

Test execution time grows linearly with number of microservices and test cases

Resource limits on test environment provisioning (CPU, memory, network)

Log storage and query performance degrade with large test runs

Orchestrator becomes a single point of failure or bottleneck

Complexity in managing dependencies and test data consistency

Solutions

Parallelize test execution by splitting test suites and environments

Use container orchestration (Kubernetes) to scale test environments dynamically

Implement log aggregation with retention policies and indexing for fast queries

Design orchestrator as a distributed system or use multiple orchestrators

Adopt contract testing and service virtualization to reduce full integration scope

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain importance of isolating test environments to avoid production impact

Discuss how stubs and mocks help test microservices independently

Highlight orchestration role in coordinating complex test scenarios

Mention logging and monitoring for debugging test failures

Address scaling challenges and solutions for large microservice systems

Practice

1. What is the main purpose of integration testing in a microservices architecture?

easy

A. To verify that different microservices communicate and work together correctly

B. To test the user interface of a single microservice

C. To check the performance of a single microservice under load

D. To test the database schema independently

Solution

1. Step 1: Understand integration testing role

   Integration testing focuses on checking how different parts of a system interact and work together.

2. Step 2: Apply to microservices context

   In microservices, integration testing ensures that services communicate and exchange data correctly.

3. Final Answer:

   To verify that different microservices communicate and work together correctly -> Option A

4. Quick Check:

   Integration testing = verify communication [OK]

Hint: Integration tests check service communication, not UI or performance [OK]

Common Mistakes:

• Confusing integration testing with UI testing
• Thinking integration tests check only one service
• Mixing integration testing with performance testing

2. Which of the following is the correct way to write a simple integration test for two microservices communicating via HTTP?

easy

A. Call one service's API and verify the response includes data from the other service

B. Test only the database queries inside one service

C. Run unit tests on each microservice separately

D. Check the UI elements of the frontend application

Solution

1. Step 1: Identify integration test action

   Integration tests call APIs to check if services interact and data flows correctly.

2. Step 2: Match with options

   Call one service's API and verify the response includes data from the other service describes calling one service and verifying response includes data from another, which is correct.

3. Final Answer:

   Call one service's API and verify the response includes data from the other service -> Option A

4. Quick Check:

   Integration test = API call + response check [OK]

Hint: Integration test means calling APIs and checking combined data [OK]

Common Mistakes:

• Testing only database queries (unit test scope)
• Running unit tests instead of integration tests
• Focusing on UI elements, not service communication

3. Consider this integration test code snippet for two microservices A and B:

response = serviceA.callEndpoint('/data')
assert 'user' in response
assert response['user']['id'] == 123
assert response['details']['status'] == 'active'

What is the expected outcome if microservice B fails to provide 'details' data?

medium

A. The test will ignore missing 'details' and succeed

B. The test will fail at the assertion checking 'details' key

C. The test will throw a syntax error

D. The test will pass because 'user' data is present

Solution

1. Step 1: Analyze test assertions

   The test checks for 'user' key and its 'id', then checks 'details' key's 'status'.

2. Step 2: Consider missing 'details' data

   If 'details' is missing, accessing response['details']['status'] causes failure or error.

3. Final Answer:

   The test will fail at the assertion checking 'details' key -> Option B

4. Quick Check:

   Missing data causes assertion failure [OK]

Hint: Missing keys cause assertion failures, not silent passes [OK]

Common Mistakes:

• Assuming test passes if some keys exist
• Confusing assertion failure with syntax error
• Thinking missing keys are ignored

4. You wrote an integration test that calls microservice A, which calls microservice B internally. The test fails intermittently with timeout errors. What is the most likely cause?

medium

A. The test code has syntax errors

B. Microservice A does not call microservice B at all

C. Microservice B is slow or unresponsive causing timeouts

D. The database schema is incorrect

Solution

1. Step 1: Understand timeout errors in integration tests

   Timeouts usually happen when a service does not respond in expected time.

2. Step 2: Analyze microservice call chain

   Since microservice A calls B internally, if B is slow or down, A's response delays causing timeout.

3. Final Answer:

   Microservice B is slow or unresponsive causing timeouts -> Option C

4. Quick Check:

   Timeout = slow/unresponsive downstream service [OK]

Hint: Timeouts usually mean slow or down called service [OK]

Common Mistakes:

• Blaming syntax errors for runtime timeouts
• Assuming no call happens without checking logs
• Confusing database issues with service timeouts

5. You want to design an automated integration test suite for a microservices system with 5 services communicating via REST APIs. Which approach best ensures reliable and scalable integration testing?

hard

A. Manually test service interactions without automation

B. Use test doubles (mocks) for all services to isolate each test

C. Test only one service at a time with unit tests

D. Deploy all services in a test environment and run end-to-end tests covering real API calls

Solution

1. Step 1: Consider integration testing goals

   Integration tests verify real communication between services, so mocks reduce test coverage.

2. Step 2: Evaluate options for reliability and scalability

   Deploying all services in a test environment and running automated end-to-end tests ensures real interactions and catches integration issues.

3. Final Answer:

   Deploy all services in a test environment and run end-to-end tests covering real API calls -> Option D

4. Quick Check:

   Real environment + automation = reliable integration tests [OK]

Hint: Run real services in test environment for true integration tests [OK]

Common Mistakes:

• Relying only on mocks, missing real integration bugs
• Skipping automation reduces test reliability
• Confusing unit tests with integration tests