with one click
testing-patterns
// TDD workflow and test strategy patterns including test pyramid, coverage strategies, mocking approaches, and anti-patterns. Load when writing tests, designing test strategies, or reviewing test coverage.
// TDD workflow and test strategy patterns including test pyramid, coverage strategies, mocking approaches, and anti-patterns. Load when writing tests, designing test strategies, or reviewing test coverage.
| name | testing-patterns |
| description | TDD workflow and test strategy patterns including test pyramid, coverage strategies, mocking approaches, and anti-patterns. Load when writing tests, designing test strategies, or reviewing test coverage. |
| license | MIT |
| metadata | {"author":"groupzer0","version":"1.1"} |
Systematic approach to effective testing. Use this skill when:
TDD is MANDATORY for new feature code. Write tests before implementation.
┌─────────────────────────────────────────┐
│ │
│ 1. RED → Write failing test │
│ 2. GREEN → Minimal code to pass │
│ 3. REFACTOR → Clean up, tests stay green │
│ 4. REPEAT │
│ │
└─────────────────────────────────────────┘
| Benefit | How TDD Delivers |
|---|---|
| Prevents over-mocking | You see what test needs before mocking |
| No test-only production code | Minimal implementation = no extras |
| Tests real behavior | Failing test proves it tests something real |
| Better design | Testable code = loosely coupled code |
| Situation | TDD? | Notes |
|---|---|---|
| New features | ✅ Always | Core workflow |
| Behavior changes | ✅ Always | Modify test first, then code |
| Bug fixes | ✅ Preferred | Write test reproducing bug first |
| Pure refactors | ⚠️ Optional | Existing tests should cover |
| Exploratory spikes | ❌ Skip | But TDD rewrite after |
If implementation arrives without tests:
See references/testing-anti-patterns.md for detailed anti-patterns and gate functions.
/\
/ \ E2E Tests (10%)
/----\ Slow, expensive, few
/ \
/--------\ Integration Tests (20%)
/ \ Medium speed, focused
/------------\
/ \ Unit Tests (70%)
/________________\ Fast, isolated, many
What: Test single function/class in isolation When: All business logic, utilities, data transformations Speed: Milliseconds Isolation: Mock external dependencies (DB, network, filesystem)
# Good unit test
def test_calculate_discount():
order = Order(items=[Item(price=100)])
assert order.calculate_discount(0.2) == 80
# Bad: tests integration, not unit
def test_order_discount():
db.create_order(...) # Touches database
api.apply_coupon(...) # External call
What: Test component interactions When: Database queries, API contracts, service boundaries Speed: Seconds Isolation: Real dependencies for component under test
# Integration: tests DB interaction
def test_user_repository_finds_by_email():
repo = UserRepository(test_db)
repo.create(User(email="test@example.com"))
found = repo.find_by_email("test@example.com")
assert found.email == "test@example.com"
What: Test full user workflows When: Critical paths, smoke tests, happy paths Speed: Minutes Isolation: None—tests complete system
# E2E: tests full flow
def test_user_can_checkout():
browser.goto("/")
browser.login("user@example.com", "password")
browser.add_to_cart("product-1")
browser.checkout()
assert browser.has_text("Order confirmed")
| Type | Target | Notes |
|---|---|---|
| Unit | 80%+ | Focus on logic, not coverage number |
| Integration | Critical paths | Don't test every permutation |
| E2E | Happy paths only | 5-10 core scenarios |
For numeric inputs:
For string inputs:
For collections:
For dates:
| Input | Scenario | Expected |
|-------|----------|----------|
| price | 0 | Free item handling |
| price | -5 | Validation error |
| price | 999999.99 | Large number display |
| name | "" | Required field error |
| name | "a"*1000 | Truncation or error |
| email | "test" | Invalid format error |
| Context | Mock What? | Reason |
|---|---|---|
| Unit tests | External dependencies (DB, network, time) | Isolation + speed |
| Integration tests | External services only | Test real component interaction |
| E2E tests | Nothing | Test real system |
⚠️ TDD prevents over-mocking: If you write the test first and watch it fail, you know exactly what needs mocking.
# Stub: Returns canned response
payment_gateway = Mock()
payment_gateway.charge.return_value = {"status": "success"}
# Mock: Verifies interactions
email_service = Mock()
order.complete()
email_service.send.assert_called_once_with(
to="user@example.com",
subject="Order Confirmed"
)
# Spy: Wraps real implementation
real_logger = Logger()
spy_logger = Mock(wraps=real_logger)
# Calls real method but records calls
expect(mockThing).toBeInTheDocument(), you're testing the mock, not the code.*-mock test IDsFull anti-pattern details: references/testing-anti-patterns.md
| Quality | Check |
|---|---|
| Readable | Can a new dev understand in 30 seconds? |
| Isolated | Does it fail independently of other tests? |
| Fast | Unit tests < 100ms, Integration < 5s? |
| Deterministic | Same result every run? |
| Focused | One assertion per test (or logical group)? |
| Maintainable | Will this break for wrong reasons? |
test_[unit]_[scenario]_[expected]
test_calculateDiscount_withExpiredCoupon_returnsZero
test_userRepository_findByEmail_whenNotFound_returnsNone
test_checkout_withEmptyCart_showsError
See references/testing-frameworks.md for framework-specific guidance.
Code review checklist, severity definitions, and document templates. Load when performing code reviews or defining review criteria.
Unified document lifecycle management. Defines terminal statuses, unified numbering via .next-id, close procedures, and orphan detection. Load at session start.
Unified Memory Contract for Flowbaby integration. Defines when and how to retrieve and store memory. Load at session start - memory is core to agent reasoning, not optional.
Common software architecture patterns, ADR templates, and anti-pattern detection. Supports architectural review, design decisions, and system documentation.
Version management, release verification, and deployment procedures for software releases. Includes semver guidance, version consistency checks, and platform-specific constraints.
Security vulnerability detection patterns including OWASP Top 10, language-specific vulnerabilities, and remediation guidance. Load when reviewing code for security issues, conducting audits, or implementing authentication/authorization.