testing-patterns
starsforks
How to install testing-patterns?
one-man-company/skills-contextmanager/testing-patterns
$npx -y skills add One-Man-Company/Skills-ContextManager --skill testing-patternsTesting patterns and principles. Unit, integration, mocking strategies.
SKILL.md
| 1 | # Testing Patterns |
| 2 | |
| 3 | > Principles for reliable test suites. |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | ## 1. Testing Pyramid |
| 8 | |
| 9 | ``` |
| 10 | /\ E2E (Few) |
| 11 | / \ Critical flows |
| 12 | /----\ |
| 13 | / \ Integration (Some) |
| 14 | /--------\ API, DB queries |
| 15 | / \ |
| 16 | /------------\ Unit (Many) |
| 17 | Functions, classes |
| 18 | ``` |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## 2. AAA Pattern |
| 23 | |
| 24 | | Step | Purpose | |
| 25 | |------|---------| |
| 26 | | **Arrange** | Set up test data | |
| 27 | | **Act** | Execute code under test | |
| 28 | | **Assert** | Verify outcome | |
| 29 | |
| 30 | --- |
| 31 | |
| 32 | ## 3. Test Type Selection |
| 33 | |
| 34 | ### When to Use Each |
| 35 | |
| 36 | | Type | Best For | Speed | |
| 37 | |------|----------|-------| |
| 38 | | **Unit** | Pure functions, logic | Fast (<50ms) | |
| 39 | | **Integration** | API, DB, services | Medium | |
| 40 | | **E2E** | Critical user flows | Slow | |
| 41 | |
| 42 | --- |
| 43 | |
| 44 | ## 4. Unit Test Principles |
| 45 | |
| 46 | ### Good Unit Tests |
| 47 | |
| 48 | | Principle | Meaning | |
| 49 | |-----------|---------| |
| 50 | | Fast | < 100ms each | |
| 51 | | Isolated | No external deps | |
| 52 | | Repeatable | Same result always | |
| 53 | | Self-checking | No manual verification | |
| 54 | | Timely | Written with code | |
| 55 | |
| 56 | ### What to Unit Test |
| 57 | |
| 58 | | Test | Don't Test | |
| 59 | |------|------------| |
| 60 | | Business logic | Framework code | |
| 61 | | Edge cases | Third-party libs | |
| 62 | | Error handling | Simple getters | |
| 63 | |
| 64 | --- |
| 65 | |
| 66 | ## 5. Integration Test Principles |
| 67 | |
| 68 | ### What to Test |
| 69 | |
| 70 | | Area | Focus | |
| 71 | |------|-------| |
| 72 | | API endpoints | Request/response | |
| 73 | | Database | Queries, transactions | |
| 74 | | External services | Contracts | |
| 75 | |
| 76 | ### Setup/Teardown |
| 77 | |
| 78 | | Phase | Action | |
| 79 | |-------|--------| |
| 80 | | Before All | Connect resources | |
| 81 | | Before Each | Reset state | |
| 82 | | After Each | Clean up | |
| 83 | | After All | Disconnect | |
| 84 | |
| 85 | --- |
| 86 | |
| 87 | ## 6. Mocking Principles |
| 88 | |
| 89 | ### When to Mock |
| 90 | |
| 91 | | Mock | Don't Mock | |
| 92 | |------|------------| |
| 93 | | External APIs | The code under test | |
| 94 | | Database (unit) | Simple dependencies | |
| 95 | | Time/random | Pure functions | |
| 96 | | Network | In-memory stores | |
| 97 | |
| 98 | ### Mock Types |
| 99 | |
| 100 | | Type | Use | |
| 101 | |------|-----| |
| 102 | | Stub | Return fixed values | |
| 103 | | Spy | Track calls | |
| 104 | | Mock | Set expectations | |
| 105 | | Fake | Simplified implementation | |
| 106 | |
| 107 | --- |
| 108 | |
| 109 | ## 7. Test Organization |
| 110 | |
| 111 | ### Naming |
| 112 | |
| 113 | | Pattern | Example | |
| 114 | |---------|---------| |
| 115 | | Should behavior | "should return error when..." | |
| 116 | | When condition | "when user not found..." | |
| 117 | | Given-when-then | "given X, when Y, then Z" | |
| 118 | |
| 119 | ### Grouping |
| 120 | |
| 121 | | Level | Use | |
| 122 | |-------|-----| |
| 123 | | describe | Group related tests | |
| 124 | | it/test | Individual case | |
| 125 | | beforeEach | Common setup | |
| 126 | |
| 127 | --- |
| 128 | |
| 129 | ## 8. Test Data |
| 130 | |
| 131 | ### Strategies |
| 132 | |
| 133 | | Approach | Use | |
| 134 | |----------|-----| |
| 135 | | Factories | Generate test data | |
| 136 | | Fixtures | Predefined datasets | |
| 137 | | Builders | Fluent object creation | |
| 138 | |
| 139 | ### Principles |
| 140 | |
| 141 | - Use realistic data |
| 142 | - Randomize non-essential values (faker) |
| 143 | - Share common fixtures |
| 144 | - Keep data minimal |
| 145 | |
| 146 | --- |
| 147 | |
| 148 | ## 9. Best Practices |
| 149 | |
| 150 | | Practice | Why | |
| 151 | |----------|-----| |
| 152 | | One assert per test | Clear failure reason | |
| 153 | | Independent tests | No order dependency | |
| 154 | | Fast tests | Run frequently | |
| 155 | | Descriptive names | Self-documenting | |
| 156 | | Clean up | Avoid side effects | |
| 157 | |
| 158 | --- |
| 159 | |
| 160 | ## 10. Anti-Patterns |
| 161 | |
| 162 | | ❌ Don't | ✅ Do | |
| 163 | |----------|-------| |
| 164 | | Test implementation | Test behavior | |
| 165 | | Duplicate test code | Use factories | |
| 166 | | Complex test setup | Simplify or split | |
| 167 | | Ignore flaky tests | Fix root cause | |
| 168 | | Skip cleanup | Reset state | |
| 169 | |
| 170 | --- |
| 171 | |
| 172 | > **Remember:** Tests are documentation. If someone can't understand what the code does from the tests, rewrite them. |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
