Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Scope: Unified testing pyramid, coverage targets, test categorization, quality gates, and CI/CD enforcement across all services.
Primary outcomes:
Consistent test categorization and execution strategy across layers.
Measurable coverage targets aligned to criticality and risk.
Automated CI quality gates that prevent regressions and untested code.
Fast developer feedback loops with deterministic test results.
2. Mission and Applicability
Use this module to establish a production-grade testing discipline for backend services, frontend applications, and AI integration points.
Apply when:
Code must be shipped to production with confidence.
Multiple developers contribute to shared codebases.
Failures in production require post-incident analysis and regression prevention.
Do not apply directly when:
Project is single-developer exploration without production requirements.
Regulatory or compliance testing requirements exceed this baseline.
3. Testing Pyramid Architecture
All projects adopt this canonical pyramid (bottom = fastest and most, top = slowest and least):
E2E Tests (5–10% of test count)
/‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
/ Contract Tests \
/ (Integration) \
/‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
/ Service/Unit Tests \
/ (60–70% of test count) \
/________________________________\
Test layer definitions:
A. Unit Tests (Base Layer)
Scope: Individual functions, classes, and modules in isolation.
Mocking: Mock all external dependencies (DB, services, APIs).
Speed: < 100 ms per test; thousands run in seconds.
Count: 60–70% of all tests.
Coverage: Business logic, algorithms, edge cases, error paths.
Example domains:
Validation logic and normalization
State machine transitions
Algorithm correctness
Error classification and mapping
B. Integration/Service Tests (Middle Layer)
Scope: Multiple components working together (e.g., service + in-process DB, service + mock external API).
Mocking: Mock external services; use real or test containers for databases.
Speed: 100 ms–2 s per test; hundreds run in seconds to minutes.
Count: 20–30% of all tests.
Scope: Service API contracts between independent services.
Mocking: Mock other services; verify request/response shape and semantics.
Speed: 100 ms–1 s per test; tens to hundreds.
Count: 5–10% of all tests.
Scope: Full system: frontend → BFF → backend → database → external services.
Mocking: Minimize mocking; use real or stubbed external services (with careful handling).
Speed: 1–10 s per test; tens run in minutes.
Count: 5–10% of all tests.
Coverage: Critical user journeys, cross-service workflows, rollback scenarios.
Example domains:
User signup → email verification → login
Create session → send message → auto-rename → list sessions
Target: Confidence that bugs reach production < 2%
Tier 4 (Low Impact – UI, Analytics, Non-Critical)
Unit test coverage:>= 50% of lines
Target: Confidence that bugs reach production < 5%
Calculation: Use coverage tools; configure to fail CI if targets not met.
5. Test Data Management
A. Factory Pattern for Realistic Data
Use factory libraries (e.g., FactoryBoy in Python, factory_bot in Ruby) to generate realistic, deterministic test data.
import factory
from users.models import User
classUserFactory(factory.django.DjangoModelFactory):
classMeta:
model = User
email = factory.Sequence(lambda n: f"user{n}@example.com")
phone = factory.Sequence(lambda n: f"+1234567890{n % 10}")
first_name = factory.Faker('first_name')
last_name = factory.Faker('last_name')
is_active = True# Usage:
user = UserFactory()
users = UserFactory.create_batch(10)
B. Fixture Management
Keep fixtures minimal; prefer factories for dynamic generation.
# Good: Small, reusable fixture@pytest.fixturedefbase_user():
return UserFactory(email="base@example.com")
# Avoid: Large fixture databases@pytest.fixture(scope="session")defall_test_data():
# Creates 10k records – slow, hard to reason about
...
C. Determinism and Seeding
Ensure all tests are deterministic:
Seed random number generators in tests.
Use explicit dates instead of now().
Avoid test ordering dependencies.
import random
from datetime import datetime, timedelta
@pytest.fixture(autouse=True)defseed_rng():
random.seed(42)
deftest_user_created_at():
now = datetime(2026, 4, 4, 12, 0, 0)
user = UserFactory(created_at=now)
assert user.created_at == now
6. Implementation Workflow
Phase A: Unit Test Coverage and Organization
Organize tests by module: tests/unit/<domain>/test_<module>.py
Use descriptive test names: test_<function>_<scenario>_<expected_result>
Follow AAA pattern: Arrange → Act → Assert.
Test both happy path and all documented error cases.
Mock all external dependencies; use dependency injection.
Use test database (separate from production/staging).
Roll back transactions after each test (or use fixtures that auto-clean).
Use factories to create fresh data per test.
@pytest.fixturedefdb_session(db):
# db fixture from pytest-django provides isolated DByield db
@pytest.fixture(autouse=True)defcleanup_after_test(db):
yield
db.session.rollback() # Auto-cleanup
External Service Mocking
Mock third-party APIs (payment, SMS, email) to avoid side effects.
Use VCR or responses library to record and replay HTTP interactions.