Menu
リポジトリに即したTypeScriptテスト設計、振る舞いの証明、独立性、モック境界の基準を適用する。ユニットテストの作成・レビュー時に使用。
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill typescript-testingThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Applies repository-aware TypeScript test design, behavior evidence, isolation, and mock-boundary criteria. Use when writing or reviewing unit tests.
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream agents can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
Coordinates subagents through scale-based planning, approval, implementation, verification, and escalation flows. Use when routing work to subagents, executing an approved work plan, or resuming autonomous execution.
| name | typescript-testing |
| description | リポジトリに即したTypeScriptテスト設計、振る舞いの証明、独立性、モック境界の基準を適用する。ユニットテストの作成・レビュー時に使用。 |
フレームワークやコマンドを選択する前に、package.json、ロックファイル、テスト設定、既存テストのimportを確認する。Vitest固有のルールはVitestが設定されている場合にのみ適用する。それ以外は、以下の振る舞い、独立性、証跡に関するルールを維持しつつ、リポジトリで設定済みのTypeScriptテストハーネスを使用する。実行可能なハーネスを特定できない場合は、確認したパスと不足しているコマンドまたは設定を報告する。
import { describe, it, expect, beforeEach, vi } from 'vitest'vi.mock() を使用単体テスト（Unit Tests）
統合テスト（Integration Tests）
E2Eテストでの機能横断検証
__tests__/ に置く{対象ファイル名}.test.ts{対象ファイル名}.int.test.tsコミットするテストはすべて有効に保つ。現行の振る舞いを保護するテストは修復する。テストを削除するのは、対象の振る舞いが不要になったことを元の要件または実装契約で確認できる場合に限る。
正常系に加え、境界値と異常系を含める。
期待値は実装上の計算から独立させる。契約の値をリテラルとして直接記述するか、独立した正規のfixtureまたは仕様から取得する。テスト対象と同じ定数や計算式から算出した期待値は、両方が誤っていても通過する。モックが入力を供給する場合、実装がそれを変換する箇所では期待値をモックの戻り値と異なる値にする。
呼び出し順序・回数ではなく結果を検証。
各テストは、値が返ったことではなく、その消費側が依存するプロパティと、操作が確立した状態を検証する。
「動作するか」を確かめるprobeが成立するのは、消費側の境界を通り、消費側が必要とするプロパティそのものを検証している場合に限る。
コマンドの終了ステータス、importの成功、オブジェクトの存在は、対象に到達できることを示すので、probeの前提条件として扱い、消費側に向いたプロパティをアサーションに置く。
| probeの意図 | 前提条件（単独では不十分） | 代わりに検証する対象 |
|---|---|---|
| モジュールが使用可能 | import が解決する、expect(mod).toBeDefined() | 消費側のエントリポイント経由でexportされた関数を呼び、その戻り値または効果を検証 |
| コマンドが動作する | 終了コード0 | 呼び出し側が消費する出力、ファイル、状態変化 |
| 設定が適用されている | 設定ファイルがパースできる | その設定が変えるはずの観測可能な振る舞い |
| migrationが実行された | コマンドが成功を報告した | 実エンジン経由のqueryがmigration後の形を返すこと |
連携がテスト対象となるin-processコンポーネントにはすべて実物を使用する。上位層の振る舞いをテストする場合は、直接依存する外部I/Oを代替する。外部アダプター、query、migration、service契約自体がテスト対象の場合は、実エンジンまたは本番相当のテストインスタンスを使用する。代替する場合も、テスト対象が送るrequestと受け入れるresponseの形を検証し、境界の契約が未検証にならないようにする。
Design DocのACにProperty注釈が付与されている場合、fc.assert(fc.property(...)) の形式でfast-checkを使用する。
モックには、テスト対象が実際に消費する範囲だけを型付けする（Pick<T, '使用するメソッド'>）。インターフェース全体を型付けしないことで、使用していないメソッドの形が変わってもテストは壊れず、消費しているメソッドの変更では壊れる。モックのオブジェクトリテラルはその抽出済み型に対して satisfies で制約し、余分なプロパティや誤った名前をコンパイル時に落とす。
モックは呼び出しパターンを検証するため、データ層の以下のプロパティはモックのみのテストでは検出されずに通過する:
振り分けルール: 上記のプロパティがテスト対象の場合 — repositoryやデータアクセス実装自体を含む — 下記のラダーに従って実エンジンに対して検証する。データアクセスがテスト対象ではなく依存先である場合はモックが正しい選択で、データ層からデータを受け取るビジネスロジック（repositoryをモック、serviceをテスト）、エラーハンドリングパス（接続失敗、タイムアウト）、データ層がテスト対象でないユニットテストが該当する。
実データベースエンジンに対するデータ層の正確性を検証するオプション:
リポジトリの根拠に合う最初の選択肢を使用する：
いずれも利用できず、データ層の正確性がテスト対象である場合は作業を止め、不足している環境前提条件を報告する。モックだけの結果は、query、schema、constraint、migrationの正確性を示す証跡にはならない。
生成されたデータアクセスコードは、構文が正しくても存在しないスキーマ要素を参照しうるうえ、モックベースのテストはどちらでもパスする。そのためDesign Docに明示的なスキーマ参照を含め、レビュー時にドキュメント化されたスキーマとデータアクセスコードを照合できるようにする。