Integration Testing Checklist

Spin up the integration cluster (EKS namespace, ECS cluster, or staging VPC) using the Terraform module that mirrors production. Confirm node sizes, autoscaling groups, and IAM roles match prod within one minor version — drift here causes failures that don't reproduce later.

Match VPC peering, security groups, and ALB rules to production. Pay attention to egress rules — many integration failures are services that can reach prod's S3 endpoint but not the integration env's because of a missing VPC endpoint.

Run the migration suite from a clean baseline against the integration RDS / Postgres instance. Load seed fixtures for tenants, users, and reference data. If a migration takes table-level locks in production, exercise it here at production-like row counts.

Confirm Datadog / New Relic agents report from each service, Sentry DSN routes to the integration project, and structured logs land in the right index. Without observability you'll be debugging integration failures from kubectl logs alone.

Create deterministic fixtures for the core user journeys — signup, checkout, subscription change. Use factory libraries (factory_bot, faker) seeded with a fixed value so test runs are reproducible across CI and local.

Cover unicode names, timezone boundaries (DST transitions), zero-quantity carts, expired tokens, and tenants with 0 / 1 / 10k records. These are where integration tests catch bugs unit tests don't — interactions between validation layers tend to disagree on edge cases.

If any fixture is derived from production exports, scrub or tokenize PII before loading into the integration database. SOC 2 and GDPR auditors will ask whether real customer email addresses live in non-prod — the answer must be no.

Execute the scrubbing pipeline (typically a one-off job that nulls out emails, phones, addresses, and replaces names from a Faker dictionary). Re-import the scrubbed dump into the integration database. Document the scrub commit SHA in the run record.

Pull the coverage report from the last main build. Identify modules where coverage dropped below the team's threshold (commonly 80%) and flag them — integration tests shouldn't be a substitute for missing unit tests.

Focus on the seams — auth service ↔ billing, API gateway ↔ workers, webhook ingest ↔ event bus. Use Postman collections or Playwright API specs that hit real endpoints, not mocked ones. The point of integration testing is the wiring between components.

Wire the suite into GitHub Actions / CircleCI / Buildkite as a required status check on the release branch. Set retry-on-failure to 1 (not 3) — masking flakes with retries is how regressions slip through.

List every external dependency the suite hits — Stripe sandbox, Auth0 tenant, SendGrid sandbox, internal services from sister teams. For each, note the SLA you can rely on during the test window and the rate limit.

Hit each vendor's status page and run a one-call smoke against each sandbox. Stripe and Auth0 sandboxes go down often enough that running a full integration suite against a degraded sandbox is the most common false-positive in this checklist.

For any unhealthy upstream, switch the suite to recorded fixtures (VCR cassettes, WireMock mappings, MSW handlers). Note in the run record which calls were stubbed so the post-deploy verification can re-test them against the real service.

Trigger the full pipeline against the release branch tag (e.g., v2024.45.0-rc.1). Run in dependency order — auth first, then services that depend on auth, then the API layer, then the worker tier. Sequencing surfaces wiring bugs that parallel runs hide.

Pull up the Datadog APM service map and the error-rate / p99 latency dashboards while the suite runs. A test that passes but doubles p99 against the auth service is still a red flag.

For each failed test, classify as code defect, environment issue, flaky test, or dependency issue. Avoid the "rerun and merge" reflex — a flaky test that masked a real race condition is the most common path to a Saturday page.

Open a ticket per defect with the failing test name, the pipeline link, the suspected commit range (use git bisect on the release branch if needed), and a reproducer. Tag with the release version so the release captain can see the open list.

Post a summary to #engineering: pass/fail count, blocking defects, dependencies that were stubbed, recommendation to ship or hold. This is the artifact the release captain reads before flipping the deploy switch.