一键导入
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.