TemplateFREE⏱️ 60-90 minutes
Integration Testing Plan Template
A structured template for planning integration tests across services, databases, and external dependencies.
Updated 2026-03-05
Integration Testing Plan
| # | Initiative | Owner | Timeline | Effort | Impact | Status | |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 | |||||||
| 3 | |||||||
| 4 | |||||||
| 5 |
#1
#2
#3
#4
#5
Edit the values above to try it with your own data. Your changes are saved locally.
Get this template
Choose your preferred format. Google Sheets and Notion are free, no account needed.
Frequently Asked Questions
How do I decide which dependencies to mock versus run as real services?+
Run real instances of dependencies you own and control (databases, message queues, internal services). Mock dependencies you do not control (external APIs, third-party services) and dependencies that are slow or expensive to run locally. The goal is maximum realism for the integration points most likely to break, without the flakiness of depending on external systems. [Testcontainers](https://testcontainers.com) and Docker Compose make running real databases and queues in CI practical.
How do I prevent integration tests from becoming slow?+
Three strategies. First, parallelize test execution by ensuring tests are data-isolated (no shared mutable state). Second, minimize setup time by reusing long-lived containers across tests in the same suite and only resetting data between runs. Third, keep the test count low. Integration tests should cover critical paths and known risk areas, not duplicate what unit tests already verify. A typical service needs 20-50 integration tests, not hundreds.
Should integration tests run on every PR or only on merge to main?+
Run a smoke subset (5-10 critical path tests) on every PR to catch obvious breakage quickly. Run the full suite on merge to main where you can afford the longer execution time. This balances fast PR feedback with thorough post-merge validation. Some teams also run the full suite nightly as a safety net.
How do I handle database schema changes in integration tests?+
Run the same migration scripts in your test environment that run in production. Use [DevOps](/glossary/devops) tooling to apply migrations before each test suite. If a migration is destructive (dropping a column), update the test data factories and test assertions in the same PR as the migration. This ensures tests always match the current schema.
What is the right ratio of integration tests to unit tests?+
The testing pyramid suggests 70% unit, 20% integration, 10% end-to-end. In practice, the ratio depends on your architecture. A monolith with complex database queries may need proportionally more integration tests. A [microservices](/glossary/microservices) system with many service-to-service calls may also skew toward more integration coverage. The key metric is not the ratio itself but the confidence that your test suite gives you before each deployment. ---
Explore More Templates
Browse our full library of PM templates, or generate a custom version with AI.