メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/yysd5/dotfiles --skill test-designコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | test-design |
| description | テストの設計・記述に関する汎用的な考え方（プログラミング言語非依存）。テストを書く・レビューする際に使用する。 |
| user-invocable | false |
このガイドラインは、良いテストを設計・記述するための 言語非依存の原則をまとめたもの。 特定のテストフレームワークやビルドツールには依存しない。 言語ごとの具体的な書き方は各言語のスキル （例: java-dev, python-dev）や tdd-workflow を参照すること。
テストは「実装が仕様を満たしていること」を保証する。 最低限、以下の観点を網羅する。
カバレッジ率は目安であって目的ではない。 数値を満たすことより、 上記の観点が実際に検証されているかを重視する。 （プロジェクトで基準がある場合はそれに従う）
各層は目的が異なる。どの層で何を検証するかを意識する。
低層（ユニット）を厚く、高層（E2E）を薄くするのが基本 （テストピラミッド）。 遅く壊れやすい高層テストに検証を寄せすぎない。
テストは「何をするか（振る舞い・結果）」を検証すべきで、 「どう実現しているか（内部実装）」に依存させない。
こうすることで、内部実装をリファクタリングしても テストが壊れにくくなる（brittle test の回避）。
良い: 公開された振る舞いを検証する
order = Order(price=100)
total = service.calculateTotal(order)
assert total == 90 # 10%割引が適用された「結果」を検証
避ける: 内部実装（private フィールド等）を検証する
assert service.discountRate == 0.1
各テストは他のテストに依存せず、 単独でも、どの順序でも、繰り返しても同じ結果になること。
避ける: 前のテストの結果に依存する
test_1_createUser()
test_2_updateUser() # test_1 が作ったデータに依存
良い: 各テストが必要な状態を自分で用意する
beforeEach: repository.deleteAll()
参考として、良いユニットテストの性質は FIRST（Fast / Independent / Repeatable / Self-validating / Timely）で覚えられる。
プロジェクト方針が異なる場合を除き、 古典派（Classical School） のアプローチを重視する。 モックの使用はシステム境界に限定し、 内部のドメインロジック同士の結合には 実オブジェクトを使用する。
実オブジェクトの組み合わせが煩雑になりすぎるケースや、 モックを使う既存コードに合わせたほうが良いケースは、 都度検討してよい。
テストケースの名称や説明は、 テストの説明を読むだけで 「システムがどのような仕様を満たしているか」が理解できるように記述する。
テストフレームワークが提供する自然言語の記述機能を積極的に活用する。
@DisplayName など、テストケースに自然言語で
タイトルを付与できる機能がある場合は、必ずこれを活用する。テストケースを記述する際、変数名、クラス名、型、null や empty といった
「コード内部の用語」を使用することは基本的には避ける。
ユーザーやシステムが「どのような状況で」「何をしたら」「どうなるか」という
ビジネス仕様（ユースケース）に焦点を当てて記述する。
| 避けるべき記述（内部用語） | 良い記述（ビジネスストーリー） |
|---|---|
userId が null のとき NullPointerException が発生すること | 未ログインのゲストユーザーがマイページにアクセスした場合はエラーになること |
orderList が empty のとき、calculateTotal が 0 を返すこと | ショッピングカートが空の状態で決済に進んだ場合、合計金額が0円になること |
user.status が ACTIVE かつ age が 20 以上のとき | アクティブな成人ユーザーが会員向けサービスを利用できること |
ロンドン学派的に「すべての依存をモックにする」手法は、 リファクタリングでテストが壊れやすくなる。 プロジェクト方針で定められている場合を除き避ける。
内部のプライベート変数の状態などを直接検証しない （→ セクション3参照）。
テスト間でデータが共有され実行順序に依存する （→ セクション4参照）。
実行して例外が出ないことだけを確認し、 結果を検証していないテストは価値が低い。 必ず期待する結果をアサートする。
何を検証しているか名前から分からないテストは避ける。 「対象 / 条件 / 期待結果」が伝わる命名を心がけるとともに、 セクション6に記載された「ビジネスストーリー」に沿った説明を付与する。
忘れないでください: テストはオプションではない。 自信を持ったリファクタリング、迅速な開発、 そして本番環境の信頼性を支えるための「命綱」である。