Integration testing in Testing Fundamentals - Framework Patterns

Framework Mode - Integration testing

Folder Structure for Integration Testing Framework

integration-testing-project/
├── src/
│   ├── main/
│   │   └── java/ (or your app source code)
│   └── test/
│       ├── integration/          # Integration test cases
│       │   ├── services/         # Tests for service layer integration
│       │   ├── repositories/     # Tests for database integration
│       │   └── controllers/      # Tests for API/controller integration
│       ├── utils/                # Helper utilities for tests
│       ├── config/               # Test configuration files
│       └── mocks/                # Mock objects or test doubles
├── build.gradle (or pom.xml)    # Build and dependency management
├── test-config.yaml              # Environment and test settings
└── README.md
    

Test Framework Layers for Integration Testing

• Test Cases Layer: Contains integration test scripts that verify how different modules work together.
• Service Layer: Business logic components that are tested in integration scenarios.
• Data Access Layer: Handles database interactions; tested to ensure correct data flow.
• Mocks and Stubs: Used to simulate external systems or components not under test.
• Utilities: Helper functions for setup, teardown, and common test operations.
• Configuration: Manages environment variables, database connections, and test parameters.

Configuration Patterns for Integration Testing

Integration tests often require different settings than unit tests. Common patterns include:

• Environment Profiles: Use separate config files or profiles (e.g., test-config.yaml) for test databases, URLs, and credentials.
• External Service URLs: Configure endpoints for dependent services or use mocks if services are unavailable.
• Database Setup: Use scripts or tools to prepare test data before tests run and clean up after.
• Parameterization: Allow tests to run against different environments by passing parameters or environment variables.

Test Reporting and CI/CD Integration

• Test Reports: Generate clear reports showing which integration tests passed or failed, including logs and error messages.
• Continuous Integration: Run integration tests automatically on code commits or pull requests using CI tools (e.g., Jenkins, GitHub Actions).
• Test Failures: Fail the build if critical integration tests fail to prevent broken code from merging.
• Notifications: Send alerts to developers when integration tests fail to enable quick fixes.

Best Practices for Integration Testing Frameworks

1. Isolate Tests: Use mocks or test databases to avoid side effects and ensure tests are repeatable.
2. Clear Setup and Teardown: Prepare the environment before tests and clean up after to keep tests independent.
3. Test Realistic Scenarios: Focus on how components interact in real use cases, not just isolated units.
4. Keep Tests Fast: Integration tests are slower than unit tests, so optimize to run only necessary scenarios.
5. Use Descriptive Names: Name tests clearly to show what integration is being verified.

Self-Check Question

Where in this folder structure would you add a new integration test for the payment processing service?

Key Result

Organize integration tests by layers and use configuration profiles to manage environments for reliable component interaction testing.

Practice

1. What is the main purpose of integration testing in software development?

easy

A. To test the software's performance under load

B. To test individual functions or methods in isolation

C. To verify the final system meets user requirements

D. To check if different modules work together correctly

Solution

1. Step 1: Understand integration testing scope

   Integration testing focuses on testing combined parts or modules of software to ensure they work together.

2. Step 2: Differentiate from other testing types

   Unit testing checks individual parts, system testing checks the whole system, and performance testing checks speed/load.

3. Final Answer:

   To check if different modules work together correctly -> Option D

4. Quick Check:

   Integration testing = module interaction check [OK]

Hint: Integration testing checks module connections, not single parts [OK]

Common Mistakes:

• Confusing integration testing with unit testing
• Thinking integration testing is the final system test
• Mixing integration testing with performance testing

2. Which of the following is the correct sequence of testing phases including integration testing?

easy

A. Integration testing -> Unit testing -> System testing

B. Unit testing -> Integration testing -> System testing

C. System testing -> Integration testing -> Unit testing

D. System testing -> Unit testing -> Integration testing

Solution

1. Step 1: Recall testing order

   Unit testing is done first on individual parts, then integration testing checks combined parts, finally system testing checks the whole system.

2. Step 2: Match sequence with options

   Only Unit testing -> Integration testing -> System testing correctly shows Unit testing -> Integration testing -> System testing.

3. Final Answer:

   Unit testing -> Integration testing -> System testing -> Option B

4. Quick Check:

   Testing order = Unit -> Integration -> System [OK]

Hint: Remember testing flows from small parts to whole system [OK]

Common Mistakes:

• Mixing up the order of testing phases
• Thinking integration testing comes after system testing
• Assuming unit testing is last

3. Consider two modules: ModuleA returns a number, and ModuleB doubles that number. Which integration test output is correct if ModuleA returns 5?

medium

A. 10

B. 5

C. 25

D. Error

Solution

1. Step 1: Understand module behavior

   ModuleA returns 5; ModuleB doubles input, so it should return 5 * 2 = 10.

2. Step 2: Determine integration output

   When ModuleB receives 5 from ModuleA, output is 10, so integration test should expect 10.

3. Final Answer:

   10 -> Option A

4. Quick Check:

   5 doubled = 10 [OK]

Hint: Multiply ModuleA output by 2 for ModuleB result [OK]

Common Mistakes:

• Confusing input and output values
• Multiplying instead of doubling
• Expecting original value without processing

4. You wrote an integration test for two modules, but the test fails with a null pointer error. What is the most likely cause?

medium

A. Modules are not properly connected or data is missing between them

B. Unit tests for each module passed successfully

C. The system testing phase was skipped

D. The test environment has too much memory

Solution

1. Step 1: Analyze null pointer error in integration

   Null pointer errors usually happen when one module expects data from another but receives nothing or null.

2. Step 2: Connect error to module interaction

   If modules are not properly connected or data is missing, integration test fails with null pointer.

3. Final Answer:

   Modules are not properly connected or data is missing between them -> Option A

4. Quick Check:

   Null pointer = missing data between modules [OK]

Hint: Null pointer in integration means missing connection/data [OK]

Common Mistakes:

• Assuming unit tests guarantee integration success
• Blaming system testing for integration errors
• Ignoring environment issues unrelated to null pointers

5. You have three modules: Auth, Profile, and Notifications. Auth sends user info to Profile, which then triggers Notifications. Which integration test scenario best checks the full flow?

hard

A. Test Auth alone for correct login

B. Test Profile updates without Auth

C. Test Auth sending data to Profile and Profile triggering Notifications

D. Test Notifications independently for message format

Solution

1. Step 1: Identify integration points

   The flow involves Auth sending data to Profile, then Profile triggering Notifications. Testing this chain checks integration.

2. Step 2: Choose scenario covering full module interaction

   Only Test Auth sending data to Profile and Profile triggering Notifications tests the full flow of data and triggers across all three modules together.

3. Final Answer:

   Test Auth sending data to Profile and Profile triggering Notifications -> Option C

4. Quick Check:

   Full flow test = Auth -> Profile -> Notifications [OK]

Hint: Test full chain of modules for integration [OK]

Common Mistakes:

• Testing modules in isolation only
• Skipping intermediate module triggers
• Ignoring data flow between modules