القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/yysd5/dotfiles --skill test-designيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| 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に記載された「ビジネスストーリー」に沿った説明を付与する。
忘れないでください: テストはオプションではない。 自信を持ったリファクタリング、迅速な開発、 そして本番環境の信頼性を支えるための「命綱」である。