Behavioral testing
Skill MasashiFukuzawa/agent-toolbox/plugins/toolbox/skills/behavioral-testing
Reusable engineering skills for Claude Code and Codex
npx -y skills add MasashiFukuzawa/agent-toolbox --skill behavioral-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
振る舞いを保護する自動テストを設計・実装・レビューする。テスト追加や壊れやすいテストの改善に使う。既存テストの実行だけには使わない。「回帰テストを追加」「モック過多を改善」を正のトリガーとし、型チェックや既存テストを繰り返すだけなら verification-loop を使う。
SKILL.md
6.3 KB, as published. Nobody here has run it
Write Meaningful Tests
目的
AIがテストコードを書く時に、数や網羅率ではなく、退行を検出し、リファクタリングを妨げず、保守しやすいテストを作る。テストは資産ではなく保守コストを持つ負債でもあるため、価値がコストを上回る場合だけ追加する。
このスキルでは、単体テストを「1単位の振る舞いを、速く、他のテストから隔離して検証するテスト」と捉える。焦点はクラスやメソッドではなく、観察可能な振る舞いである。
最初に止まる条件
次の条件に当てはまる場合は、テスト実装に入る前に質問するか、characterization test に限定するか、作業を止める。
- 期待値の根拠が現在の実装しかない。
- 仕様、issue、PRD、公開API契約、バグ再現条件、既存の明示的期待値のどれも見つからない。
- 境界条件、丸め、時刻の包含/排他などの仕様が未確定なのに、AIが期待値を補う必要がある。
- private method や内部呼び出ししか観察点がない。
- 既存のテスト規約、fixture/factory、実行コマンド、外部依存の扱いを確認していない。
- 外部サービスへ実通信しないと成立しない。
- テストを通すためだけにプロダクションコードを汚染しそうである。
判断フロー
- 仕様オラクルを特定する。 仕様、issue、PRD、公開API契約、ユーザー報告、バグ再現手順、既存の明示的な期待値を探す。実装の分岐や定数を丸写しして期待値を作らない。
- 観察可能な振る舞いを1つ選ぶ。 クライアントが達成したい結果、公開APIの戻り値、公開状態、外部から観察できる副作用に絞る。
- コードを分類する。 ドメイン/アルゴリズムは単体テスト、コントローラは統合テスト、取るに足らないコードは原則テストしない。複雑さと協力者が両方多いコードは、先に責務分離を提案する。
- 依存を分類する。 管理下依存は実物で状態を確認する。管理下にないプロセス外依存だけを、所有する境界アダプタのモックまたはスパイに置き換える。システム内コミュニケーションは検証しない。
- テスト手法を選ぶ。 出力値ベースを最優先する。必要に応じて状態ベース、ドメインイベント、統合テストでの境界スパイを選ぶ。コミュニケーションベースは外部から観察可能な境界通信に限定する。
- 既存規約に合わせて実装する。 既存のテストランナー、命名、fixture、factory、assertion library、DB初期化、cleanup、CIコマンドに合わせる。
- 最小の検証コマンドを実行する。 追加・変更したテストを最小範囲で実行し、必要なら関連テストまで広げる。
実装前チェック
テストを書く前に、短くてもよいので次を自分の中で埋める。
仕様根拠:
観察する振る舞い:
テスト対象分類:
テストレベル:
依存の扱い:
使う既存fixture/factory:
時刻/乱数/並行性/外部I/Oの扱い:
実行コマンド:
この表を埋められない場合、テストを書くよりも先に不足情報を調べる。調べても埋まらない場合は、ユーザーに確認する。
モックのルール
- 単体テストで安易にモックを作らない。設計が悪くてテストしづらい箇所をモックで隠さない。
- スタブは入力を供給するために使う。スタブとのやり取りは検証しない。
- モック/スパイは外向きのコミュニケーションを検証するために使う。
- モック対象は自分たちが所有する境界アダプタにする。サードパーティSDKや具象クラスを直接モックしない。
- モックを使う場合は、期待する呼び出しと、起きてはいけない呼び出しの両方を検討する。
テストの形
- AAA（Arrange, Act, Assert）を保つ。同じフェーズが複数回出るなら、複数の振る舞いを1つのテストに詰めている可能性を疑う。
- Act が複数行になる場合、公開APIの設計や抽象化不足を疑う。
- テスト名は実装名ではなく、ドメイン上の事実や振る舞いを表す。
- 過度な共有fixtureより、テスト内で意図が読めるfactory/helperを優先する。
- カバレッジ稼ぎ、同義反復assert、実装ロジックのコピー、広すぎるsnapshotを避ける。
- 境界条件が仕様にない場合、テストで勝手に固定しない。確認するか、仕様化済みの範囲だけをテストし、未確定境界は明示的に保留する。
参照ファイル
- テスト戦略、単体/統合境界、コード分類、依存分類、モック判断で迷う場合は
references/testing-principles.mdを読む。 - テスト実装に入る場合は
references/ai-test-writing-protocol.mdを読む。 - 既存テストのレビュー、壊れやすいテスト、過剰モック、snapshot乱用を扱う場合は
references/test-smells-and-refactor-recipes.mdを読む。 - DBを含む統合テストを扱う場合は
references/db-integration-testing.mdを読む。
出力方針
- テストを追加した場合は、何を仕様根拠にしたか、どの振る舞いを守るか、どのコマンドで検証したかを報告する。
- テストを書かない判断をした場合は、なぜ価値がコストを下回るか、または何の仕様根拠が不足しているかを明確に伝える。
- テスト容易性のためのリファクタリングが必要な場合は、テストだけで隠さず、最小の設計改善として提案する。