Integration testing verifies that different modules or services work correctly together. While unit tests check individual components in isolation, integration tests check the connections between them.
Why Integration Testing Matters
Individual components can pass all unit tests and still fail when connected. This happens because:
- Data format mismatches — Module A sends XML, Module B expects JSON
- Interface changes — API contract changed but consumer wasn't updated
- Timing issues — One service responds slower than expected
- Error handling gaps — Module A handles errors differently than Module B expects
- Data flow problems — Information gets lost or transformed incorrectly between components
Types of Integration Testing
Big Bang Integration All modules integrated at once, then tested together.
- Pros: Simple to set up, good for small systems
- Cons: Hard to isolate failures, debugging is difficult, risky
- Best for: Small applications with few components
Top-Down Integration Start from the top (main module) and integrate downward, using stubs for lower modules.
- Pros: Tests major functions early, follows user flow
- Cons: Requires many stubs, lower modules tested late
- Best for: UI-driven applications
Bottom-Up Integration Start from the bottom (foundational modules) and integrate upward, using drivers for higher modules.
- Pros: Tests critical infrastructure first, fewer stubs needed
- Cons: UI tested last, requires drivers
- Best for: Utility-heavy systems, microservices
Sandwich (Hybrid) Integration Combines top-down and bottom-up, meeting in the middle.
- Pros: Parallel development, tests both ends early
- Cons: Complex to manage, requires both stubs and drivers
- Best for: Large, complex systems
Integration Testing in Practice
API Integration Testing
The most common type today. Test that services communicate correctly:
- Request format: Correct HTTP method, headers, body
- Response handling: Parse response correctly, handle all status codes
- Authentication: API keys, tokens, OAuth flows
- Error scenarios: Timeouts, rate limits, service unavailable
Tools: Postman, REST Assured, Playwright (for API testing)
Database Integration Testing
Verify application-database interactions:
- CRUD operations create correct records
- Transactions commit and rollback properly
- Connection pooling works under load
- Database queries return expected results
Third-Party Integration Testing
Test connections with external services:
- Payment gateway (Stripe, PayPal)
- Email service (SendGrid, Resend)
- Authentication providers (OAuth, SSO)
- Cloud storage (S3, Azure Blob)
Use sandbox/test environments for third-party services.
Integration Testing vs Other Levels
| Level | Scope | Focuses On | Run By | |-------|-------|-----------|--------| | Unit | Single function/class | Internal logic | Developers | | Integration | Module connections | Interfaces & data flow | QA + Developers | | System | Entire application | End-to-end workflows | QA | | Acceptance | Business requirements | User needs met | Business users |
Best Practices
- Test interfaces first — focus on the data flowing between modules
- Use contract testing — define and verify API contracts
- Automate where possible — integration tests are great automation candidates
- Test error paths — what happens when a service is down or returns unexpected data?
- Maintain test data — integration tests need consistent, realistic data
- Keep tests independent — each test should be able to run in isolation
Where Integration Testing Fits in CI/CD
Integration tests typically run after unit tests but before E2E tests:
- 1.Unit tests (seconds)
- 2.Integration tests (minutes)
- 3.Smoke tests (minutes)
- 4.E2E tests (longer)
This is a core topic in the ISTQB syllabus and is frequently asked in QA interviews.