freemo
d9e5668cec
Fixes and improvements from exhaustive audit: Consistency fixes in SKILL.md: - 'Pipe & Filter' → 'Pipe and Filter' (one stray '&' found and corrected) - 'Singleton for factory instance' → clarified to 'register factory as singleton-scoped via DI container' (less misleading wording) - Documentation Format section updated with note that SKILL.md itself is the authoritative source for related-pattern combinations Coverage fix — Related Patterns sections: - Added '## Related Patterns' to ALL 94 pattern files (was 0/94) - Each section lists 3–6 related patterns with relationship descriptions - Covers: why they're related, when to prefer one vs the other, and which are often confused SOLID principles → Creational → Structural → Behavioral → Architectural → Concurrency → Functional → Resilience → Data Access → Messaging → Testing → Error Handling → Microservice — all 13 categories covered Code verification: - Python: 0 failures (all 85 testable blocks pass) - Go: 0 failures (all 76 testable blocks pass) - JavaScript: 0 failures (all 78 testable blocks pass) - All 239 code blocks verified correct after edits Final skill state: - 108 files, 36,524 lines across 13 reference categories - 94/94 pattern files have Related Patterns sections - 2,815-line SKILL.md with 67 decision trees, 23 scenarios, 0 broken references, 0 naming inconsistencies
Testing Patterns
Overview
Testing patterns provide structured approaches to writing reliable, maintainable, and expressive tests. They address common challenges: isolating units under test, structuring test logic clearly, managing complex test data, and abstracting UI interactions for end-to-end tests.
Pattern Comparison
| Pattern | Purpose | Scope | Key Benefit |
|---|---|---|---|
| Test Doubles | Replace real dependencies with controlled substitutes | Unit / Integration | Isolation from external systems |
| Arrange-Act-Assert | Structure each test in three clear phases | Unit / Integration | Readability and consistency |
| Given-When-Then | Express tests as BDD scenarios | Acceptance / BDD | Business-readable specifications |
| Page Object | Encapsulate UI page structure behind an API | UI / E2E | Decouple tests from page layout |
| Test Data Builder | Construct complex test fixtures fluently | Unit / Integration | Reduce boilerplate, improve clarity |
When to Use Which
- Need to isolate a unit from its dependencies? Use Test Doubles (mock, stub, spy, fake, dummy).
- Want a simple, consistent test layout? Use Arrange-Act-Assert for any unit or integration test.
- Writing acceptance tests with stakeholders? Use Given-When-Then for natural-language scenarios.
- Testing web UIs that change layout frequently? Use Page Object to centralise selectors.
- Creating many similar but slightly different test objects? Use Test Data Builder for fluent construction.
Relationships Between Patterns
- Arrange-Act-Assert and Given-When-Then are structural alternatives; AAA is more common in unit tests, GWT in BDD.
- Test Doubles are used inside the "Arrange" / "Given" phase of either structure.
- Test Data Builder simplifies the "Arrange" / "Given" phase when fixtures are complex.
- Page Object is typically combined with AAA or GWT for UI tests.
Further Reading
- xUnit Test Patterns by Gerard Meszaros
- Growing Object-Oriented Software, Guided by Tests by Freeman & Pryce
- Martin Fowler's "Mocks Aren't Stubs" article