メニュー
Writes behavior-focused tests using Testing Trophy model with real dependencies. Use when writing tests, choosing test types, or avoiding anti-patterns like testing mocks.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | writing-tests |
| description | Writes behavior-focused tests using Testing Trophy model with real dependencies. Use when writing tests, choosing test types, or avoiding anti-patterns like testing mocks. |
Core principle: Test user-observable behavior with real dependencies. Tests should survive refactoring.
"The more your tests resemble the way your software is used, the more confidence they can give you." — Kent C. Dodds
Why this matters: Tests exist to give you confidence. The Testing Trophy prioritizes integration tests because they test real behavior across real modules — giving maximum confidence per test written. Unit tests in isolation often just test mocks, not your actual system.
| Priority | Type | When |
|---|---|---|
| 1st | Integration | Default - multiple units with real dependencies |
| 2nd | E2E | Complete user workflows |
| 3rd | Unit | Pure functions only (no dependencies) |
Default: Don't mock. Use real dependencies.
Only mock:
Never mock:
Before mocking, ask: "What side effects does this have? Does my test need those?" If unsure, run with real implementation first, then add minimal mocking only where needed.
Complete user workflow? → E2E test
Pure function (no side effects)? → Unit test
Everything else → Integration test
| Context | Assert On | Avoid |
|---|---|---|
| UI | Visible text, roles | CSS classes, internal state |
| API | Response body, status | Internal DB state |
| Library | Return values | Private methods |
| Pattern | Fix |
|---|---|
| Testing mock calls | Test actual outcome |
| Test-only methods in production | Move to test utilities |
sleep(500) | Poll for actual condition |
| Asserting on internal state | Assert on observable output |
| Incomplete mocks | Mirror real API completely |
Wait for the actual condition, not a guess about how long it takes.
// Bad: arbitrary delay
await new Promise(r => setTimeout(r, 2000));
expect(element).toBeVisible();
// Good: poll for condition
await waitFor(() => expect(element).toBeVisible());
Prefer framework built-ins:
findBy queries, waitForexpect(locator).toBeVisible()asyncio.wait_for, tenacityLanguage-specific waiting patterns:
Remember: Behavior over implementation. Real over mocked. Outputs over internals.
Writing style and tone guide for human-sounding content. Use when writing documentation, READMEs, commit messages, PR descriptions, blog posts, LinkedIn posts, social media content, or any user-facing content.
Executes implementation plans with smart task grouping. Groups related tasks to share context, parallelizes across independent subsystems.
Diagnose and fix tests that pass in isolation but fail when run concurrently. Covers shared state isolation, resource conflicts, and timing-based flakiness.
Guides CI/CD pipeline architecture, security hardening, and deployment strategies for GitHub Actions. Use when designing workflows, securing supply chains, optimizing build performance, configuring deployments, managing infrastructure as code pipelines, or setting up pipeline observability.
Defines product features from a PM perspective before technical planning begins. Use when scoping new features, writing product specs, defining user problems, choosing what to build, researching existing patterns, or bridging the gap between strategy and implementation. Covers JTBD analysis, competitive research, UX/DX experience definition, and scope negotiation for consumer, B2B, and developer tool products.
Guides clean, scalable system architecture during the build phase. Use when designing modules, defining boundaries, structuring projects, managing dependencies, or preventing tight coupling and brittleness as systems grow.