ワンクリックで
testing-patterns
Use when planning test strategies, writing unit/integration tests, or selecting mocking patterns.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when planning test strategies, writing unit/integration tests, or selecting mocking patterns.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Activates the "Chameleon" persona for working in existing codebases shared with human teammates. Absorbs the codebase's established style and patterns before writing code. Issues explicit warnings when mimicking sub-optimal patterns. Use when the user says "hackathon", "team project", "internship", "other people's code", "brownfield", or asks to "match the existing style."
Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
Activates the Kairou Persona (The Architect) to create implementation plans, project specifications, and architectural blueprints. Use when the user asks to "plan", "roadmap", or "architect" a solution.
Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.
Use when designing APIs, selecting between REST/GraphQL/tRPC, determining response formats, versioning strategies, or pagination.
Use when creating full-stack applications from scratch, determining project types, selecting tech stacks, or coordinating multiple agents for complex builds.
| name | testing-patterns |
| description | Use when planning test strategies, writing unit/integration tests, or selecting mocking patterns. |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
Principles for reliable test suites.
Guides:
- See
testing-guide.mdfor comprehensive Python/JS testing strategies.- See
logging-guide.mdfor structured logging patterns.
/\ E2E (Few)
/ \ Critical flows
/----\
/ \ Integration (Some)
/--------\ API, DB queries
/ \
/------------\ Unit (Many)
Functions, classes
| Step | Purpose |
|---|---|
| Arrange | Set up test data |
| Act | Execute code under test |
| Assert | Verify outcome |
| Type | Best For | Speed |
|---|---|---|
| Unit | Pure functions, logic | Fast (<50ms) |
| Integration | API, DB, services | Medium |
| E2E | Critical user flows | Slow |
| Principle | Meaning |
|---|---|
| Fast | < 100ms each |
| Isolated | No external deps |
| Repeatable | Same result always |
| Self-checking | No manual verification |
| Timely | Written with code |
| Test | Don't Test |
|---|---|
| Business logic | Framework code |
| Edge cases | Third-party libs |
| Error handling | Simple getters |
| Area | Focus |
|---|---|
| API endpoints | Request/response |
| Database | Queries, transactions |
| External services | Contracts |
| Phase | Action |
|---|---|
| Before All | Connect resources |
| Before Each | Reset state |
| After Each | Clean up |
| After All | Disconnect |
| Mock | Don't Mock |
|---|---|
| External APIs | The code under test |
| Database (unit) | Simple dependencies |
| Time/random | Pure functions |
| Network | In-memory stores |
| Type | Use |
|---|---|
| Stub | Return fixed values |
| Spy | Track calls |
| Mock | Set expectations |
| Fake | Simplified implementation |
| Pattern | Example |
|---|---|
| Should behavior | "should return error when..." |
| When condition | "when user not found..." |
| Given-when-then | "given X, when Y, then Z" |
| Level | Use |
|---|---|
| describe | Group related tests |
| it/test | Individual case |
| beforeEach | Common setup |
| Approach | Use |
|---|---|
| Factories | Generate test data |
| Fixtures | Predefined datasets |
| Builders | Fluent object creation |
| Practice | Why |
|---|---|
| One assert per test | Clear failure reason |
| Independent tests | No order dependency |
| Fast tests | Run frequently |
| Descriptive names | Self-documenting |
| Clean up | Avoid side effects |
| ❌ Don't | ✅ Do |
|---|---|
| Test implementation | Test behavior |
| Duplicate test code | Use factories |
| Complex test setup | Simplify or split |
| Ignore flaky tests | Fix root cause |
| Skip cleanup | Reset state |
Remember: Tests are documentation. If someone can't understand what the code does from the tests, rewrite them.