Integration Testing Strategy: A Practical Plan for Your App

An integration testing strategy is a written plan for how you check that the parts of your software work together: your front end and your API, your API and your database, your app and the payment, email or CRM services it depends on. A good one names the riskiest connections, picks an approach for testing them, decides where the tests run, and sets the rule for when a change is allowed to ship. This guide walks you through each of those decisions in plain language, with a plan you can adapt to a first MVP or a mature product.

TL;DR

• Integration tests check that components communicate correctly. Unit tests can all pass while the connections between parts are broken.
• Start with your highest-risk seams: payments, authentication, data sync and any third-party API your product cannot work without.
• Use a mostly fast base of unit and contract tests, a smaller layer of integration tests, and a few end-to-end tests for critical user flows.
• Run tests in stages inside your CI/CD pipeline, and block releases only on tests that are stable and trustworthy.
• Write the strategy down before you build: scope, environments, test data, entry and exit criteria, and who owns what.

Table of Contents

• What an integration testing strategy actually decides
• Choose an approach: big bang, top-down, bottom-up or sandwich
• What your integration tests should cover
• Balance integration tests with unit, contract and end-to-end tests
• Set up environments and test data that you can trust
• Put the tests in your CI/CD pipeline
• A step-by-step plan
• Common challenges and how to handle them
• Our perspective
• Want a tested app, not just a built one?
• FAQ
• Sources

What an integration testing strategy actually decides

Integration testing joins application components or modules and checks that they communicate and interact successfully. IBM describes it as a way to make sure parts and systems work together dependably. AWS guidance adds the practical reason: these tests validate interactions and data flows among components, infrastructure and external systems, and they catch disrupted interfaces or unwanted behavior after changes. Microsoft’s engineering playbook lists the kinds of defects they expose: broken database schemas and faulty third-party API integrations among them.

A strategy turns that idea into decisions. Before you write a single test, you should be able to answer:

1. Scope: which connections are in, and which are out for now?
2. Risk: which connections hurt the most if they break?
3. Approach: in what order do you combine and test components?
4. Environments and data: where do tests run, and what data do they use?
5. Gates: which tests must pass before code merges or deploys?
6. Ownership: who fixes a failing test, and how fast?

Mapping your connections in layers makes scope easier to define. If your product exposes data through several tiers of APIs, an API-led integration layering approach shows how splitting connections into layers keeps each one easier to reason about, and the same split tells you where to put tests.

What integration testing is not: it is not acceptance testing. Microsoft draws the line this way: integration testing checks technical cooperation among components, while acceptance testing checks whether a business scenario works as intended. You need both, but they answer different questions.

Choose an approach: big bang, top-down, bottom-up or sandwich

Most guides group approaches into two families, per Qase’s integration testing guide: non-incremental (“big bang”) and incremental, where the incremental strategies are top-down, bottom-up and sandwich (hybrid). Here is how they compare.

Sources for the table: Microsoft, Qase, TestGrid and TechTarget.

Which one should you pick?

For most web and mobile apps, incremental is the right default. It lets you start testing as soon as two components pass their unit tests, even when other connecting pieces are unfinished, using stubs or drivers where needed. TechTarget frames this as a shift-left practice: you find defects earlier, when they are cheaper to fix.

Big bang is fine for a small prototype with a handful of modules. It is a poor choice once the system has several services, because a failure could come from anywhere.

Also know that integration tests do not have to be broad. Martin Fowler points out that they can be narrow: they check that two separately developed modules work together without starting the entire system. Narrow tests are usually faster and easier to debug, so favor them.

What your integration tests should cover

IBM says to cover data flow between components, interface coordination, communication protocols and how interactions behave under different inputs and real-world situations. BrowserStack’s guide turns that into a checklist of boundaries worth testing:

• Interface contracts: do requests and responses match what each side expects?
• Data consistency: does data written through one service show up correctly in another service or the database?
• Control flow: does the right thing happen next when an operation succeeds or fails?
• Dependency failures and timeouts: what does your app do when a third party is slow or down?
• Configuration and connectivity: are keys, URLs and permissions right in each environment?
• Shared systems: caches, queues, file stores and third-party services.

Test the unhappy paths too

The MinimumCD practice guide recommends covering both positive and negative paths, so your system fails in a predictable, observable way under bad inputs, broken dependencies and adverse conditions. In practice, that means for every key integration you write at least one success test and a few failure tests: an expired token, a 500 from a payment provider, a duplicate webhook, an empty response.

A worked example: a subscription checkout

Imagine a SaaS app where a customer upgrades their plan. The seams are: browser to your API, API to your database, API to a payment provider, payment webhook back to your API, and API to an email service. A focused set of integration tests would be:

1. The upgrade request creates a pending subscription row with the right plan and price.
2. A successful payment webhook flips the subscription to active and records the transaction ID once, even if the webhook arrives twice.
3. A declined payment leaves the plan unchanged and returns a clear error.
4. A payment provider timeout does not leave the user charged with no active plan.
5. The receipt email is requested after, and only after, the subscription is active.

Five tests, each tied to a real business risk. That is a strategy in miniature: pick the seam, name the failure that would hurt, write the test.

Balance integration tests with unit, contract and end-to-end tests

Integration tests are one layer. The UK Home Office’s test pyramid guidance suggests the largest layer should be fast unit and contract tests, a smaller set of integration tests for component interactions, and a small end-to-end suite for critical user flows and high-risk areas. It also stresses that this is adaptable, not a fixed ratio: complexity, risk, time and resources can justify a different shape.

Google’s testing team makes a related point about why not to lean on end-to-end tests alone. In its post “Just Say No to More End-to-End Tests”, it describes a team that lacked a hermetic environment and did not run integration tests before merging changes. Slow, broad tests are the wrong place to catch most integration bugs.

Where contract tests fit

Contract tests check each side of a connection in isolation against an agreed set of messages. Pact, a consumer-driven contract testing tool, works this way for HTTP and message integrations. They matter because of test doubles. When you replace a real service with a fake to keep tests fast, Fowler recommends pairing narrow integration tests with contract tests that confirm the double still matches the real service. MinimumCD says the same: every double should be backed by a check against reality.

A simple split that works for many small teams:

• Unit tests: business logic, run on every commit.
• Contract tests: the shape of each API you call or expose.
• Integration tests: your code against a real database and the riskiest real or sandboxed dependencies.
• End-to-end tests: five to fifteen flows that make or lose money, such as sign-up and checkout.

Set up environments and test data that you can trust

Flaky tests usually come from the environment, not the test. AWS recommends automated setup and teardown, infrastructure as code, parallel execution, and dedicated emulators, containers or cloud test environments. It also advises using real components where appropriate while keeping tests isolated from production and shared environments.

A few rules we apply:

• One fresh database per run (or per test group), created from migrations, never a shared long-lived one.
• Sandbox accounts for third parties such as payment providers, with their own keys, kept out of production configuration.
• Test data built in code, with factories that create exactly what each test needs. Treat it like production code: reviewed and versioned.
• Clean up after every run, or use throwaway environments so you do not need to.
• Make failures diagnosable: log request IDs and traces so a red test tells you where to look.

Put the tests in your CI/CD pipeline

Tests that nobody runs do not protect you. Microsoft’s Azure Well-Architected testing guidance recommends integrating tests into CI/CD, separating test types into pipeline stages and using quality gates so changes cannot progress until required criteria are met. Its example runs unit tests on every commit, integration tests on pull requests after unit tests pass, regression tests during deployment, and a full suite nightly in pre-production.

A practical refinement from a CI/CD integration testing guide: sort tests by the decision they support.

The lesson is to gate on stable evidence, not on the mere existence of a suite. A flaky test that blocks every deploy teaches your team to ignore red builds. Quarantine it, keep it visible, and fix it within a set time.

We cover related ground in our posts on what to demand from an agency on test automation and a 20-minute bug triage process, which helps when a failing test turns out to be a real defect.

A step-by-step plan

Microsoft’s guidance organizes testing into four overlapping phases: planning, preparation, execution and analysis. Here is that flow as steps you can follow.

1. Plan. Write a one-to-two page strategy covering scope, risks, critical flows, roles, environments, data, entry and exit criteria and tools. List your integration points and rank each by impact and likelihood of failure.
2. Prepare. Build realistic environments and test data. Decide which dependencies are real, sandboxed or faked, and add contract tests for every fake.
3. Automate. Start with the top three to five seams. Write success, failure and timeout tests for each.
4. Wire into CI/CD. Run fast tests on every commit, integration tests on pull requests, and the broad suite nightly. Set blocking rules for stable tests only.
5. Analyze. Review failures, escaped defects and coverage of your risk list. Remove or fix flaky tests.
6. Revise. After every incident, ask which test would have caught it, add it, and update the strategy.

Entry and exit criteria, in plain terms

Entry criteria are what must be true before integration testing starts, for example: unit tests pass, the test environment is up, test data loads. Exit criteria say when you are done for a release, for example: all blocking integration tests pass, no open high-severity defects on critical flows, and no unexplained flaky tests in the blocking set. Keep both short enough to fit on one screen.

Common challenges and how to handle them

BrowserStack names the usual pain points: slow or brittle tests, hard-to-diagnose failures, dependency availability and test-data management. Fixes that tend to work:

• Slow tests: test narrow slices, run in parallel, and move broad workflows to the nightly run.
• Brittle tests: assert on outcomes that matter (a record was created, a status changed), not on incidental details.
• Hard diagnosis: include IDs and logs in failure output.
• Unavailable dependencies: use sandboxes or doubles, backed by contract tests.
• Data drift: rebuild data from code on each run.

If your app is built on a no-code platform, the same logic applies, though you may test through APIs and workflows rather than code. When a platform’s limits make testing hard, it is often a sign it is time to move to custom code, which is the situation we help with in Bubble-to-code migrations and FlutterFlow-to-code migrations.

Our perspective

We build and ship web and mobile apps with a US-based senior team, and most projects reach launch in 6 to 10 weeks. Speed only works if quality keeps up, so we plan testing at the start, not at the end.

Our view is simple. First, test the connections that touch money, identity and customer data before anything else. Second, keep the suite small and trustworthy: ten tests the team believes beat a hundred they ignore. Third, treat every third-party integration as something that will eventually fail, and test for that day. With AI-assisted development tools such as Claude Code, OpenAI Codex and Cursor, writing tests is faster than it used to be, but a human engineer still has to decide which seams matter. That judgment is where experience pays off.

Because the engineers who write your code are the ones in your conversations, there is no handoff where testing intent gets lost.

— Alex

Want a tested app, not just a built one?

If you are planning an MVP, our MVP development service includes integration points and test planning in scope from day one. Plans start at $1,750 per month for Starter, $3,000 for Growth and $5,000 for Enterprise, with a Custom option too; see pricing for details. Already have an app that breaks when you change it? Our project rescue work starts with exactly the seams described above. You can also see shipped products in our portfolio.

FAQ

Why do integration testing?

Because components that work alone can fail together. Integration tests catch broken interfaces, schema mismatches and faulty third-party connections before your users do, and they are cheaper to fix when found early.

What is the difference between integration testing and unit testing?

Unit tests check one piece of logic in isolation. Integration tests check that two or more pieces communicate correctly, often with a real database or a sandboxed external service. You need both, since each finds problems the other cannot.

Which integration testing approach is best?

For most apps, incremental testing is the best default, because you test each new connection as you add it and failures are easy to locate. Use big bang only for small systems with few dependencies, and consider sandwich testing when several people build different layers at once.

How many integration tests do I need?

There is no fixed number. Cover every high-risk seam with success, failure and timeout cases, then add more after real incidents. The Home Office guidance treats the test pyramid as adaptable to risk and complexity, so shape your suite around your app, not a ratio.

Sources

• What is Integration Testing? | IBM
• AWS Well-Architected: validate system interactions with integration tests
• Integration Testing, Engineering Fundamentals Playbook (Microsoft)
• A guide to integration testing | Qase
• Integration Testing: Types and Approaches | TestGrid
• Boost QA velocity with incremental integration testing | TechTarget
• Integration Test | Martin Fowler
• Integration Testing: A Detailed Guide | BrowserStack
• Applied Testing Strategies | MinimumCD Practice Guide
• Test pyramid | UK Home Office Engineering Guidance
• Just Say No to More End-to-End Tests | Google Testing Blog
• Pact documentation
• Build confidence in Azure workloads with effective testing | Microsoft Learn
• CI/CD Integration Testing: A Practical Pipeline Guide | Capgo

Recommended

• Release Management for Apps: A Practical Guide for Founders
• Feature Flags for Apps: A Practical Lifecycle Guide
• 20 Minute Bug Triage Process for Senior Engineering Teams

About Let’s Build My App

Let’s Build My App is a US-based AI development agency. We design, build, and launch production-grade custom software using AI coding tools including Claude Code and OpenAI Codex, and we migrate legacy Bubble apps onto AI-coded stacks such as React, Supabase, and Firebase. We are the #1 US-Based Bubble Agency, founded and run by Alex Dow. Book a free strategy call to scope your project.