テストを制御標本として扱う
概要
テストは制御標本です。すなわち、期待値を固定することで、振る舞いの変化を可視化します。その規律は「テストをコードに合わせて修正するのではなく、なぜ両者が矛盾するのかを理解する」ことです。
ルール
-
振る舞いの変更にはテストファースト。 失敗するテストを書き、それが正しい理由で失敗するのを確認してから、最小限のコードを書いてパスさせます。テストが失敗するのを確認しなかった場合、そのテストが意図したものを正しくテストしているとは言えません。このループ自体は
superpowers:test-driven-developmentに委ねられますが、このスキルはテストが何を含むべきか、そしてテストが存在するときに失敗が何を意味するかを規定します。このルールは、そのスキルがインストールされているかどうかに関わらず適用されます。 -
構造変更は変更されていない既存スイートで検証する。 純粋な構造変更（リネーム、移動、分割、抽出など、観測可能な振る舞いに変更がないもの）には新しいテストは不要です。その検証基準は逆です。「既存のテストスイート全体が、テストを一切編集せずにパスすること」。これがテストファーストがここで適用されない理由です。指定すべき振る舞いがないため、意味のある形でテストが先に失敗することはあり得ません。構造変更によってテストの編集が必要になった場合、それは構造変更ではありません。停止し、次のルールに従って再分類してください。
-
契約境界を越えるリネームはリファクタリングではない。 問われるのは「コードの振る舞いが変わったか」ではなく、「その名前が自分が制御できない何かに対して観測可能か」です。
リネーム対象 分類 検証基準 内部シンボル、プライベートヘルパー、ローカルファイル 構造変更 既存スイートが未編集でパス エクスポートされた関数、API/GraphQLフィールド、ルート、CLIフラグ、DBカラム、イベント名、設定キー 振る舞い変更 — コンシューマを壊す テストファースト + 追加と非推奨化 公開リネームは同じデータに対して同じことを行うものでも、名前が契約であったため依然として破壊的変更です（Hyrumの法則 —
performance-and-scaleを参照）。これを振る舞い変更として扱います。新しい名前をテストファーストサイクルで追加し、古い名前とそのパスするテストを非推奨期間中存続させ、コンシューマが移行した後にのみ古い名前を削除します。3つ目のケースは、テストが名前を文字列として参照する場合です — スナップショット、DIコンテナキー、リフレクション、フィクスチャパスなど。これらは内部リネームによって壊れます。これはルールの失敗ではなく、テストが実装の詳細に結合していたことのシグナルです。結合を修正し、再ベースライン化は行わないでください。
-
リファクタリングでテストを編集してはならない。要件変更では編集する。 異なる行為：
- リファクタリングでテストが壊れる → テストが意図しない振る舞い変更を捕捉した。停止し、理解せよ。 リファクタリングを通すためにテストを編集することは、計装を壊すことです。
- 要件が実際に変更された → テストを意図的に更新し、それ自体がレビュー可能な変更として記録します。
- 禁じられた行為は、無言の再ベースライン化です。
-
対称的なカバレッジ — すべてのルールを両方向でテストする。 許可されたアクターができることと、許可されていないアクターができないことを証明する。ハッピーパスのみのテストはルールの半分しかテストしていません。
-
権限/ロールルールはマトリックスである。 すべての意味のある（ロール × アクション × リソース）セルについて、許可と拒否の両方をテストする。新しいロールは、その拒否ケースが存在するまで不完全です。突然パスするようになったdenyテストはセキュリティリグレッションです — 明示的にレビューして受け入れ、決して再ベースライン化しないでください。
-
エントリーポイントは無言で追加・削除してはならない。 ルート、コマンド、エンドポイントにはそれぞれ存在確認とスモークテストを行い、追加・削除によってテストの変更が強制されるようにします。
-
テストはサイズごとに分類する： Small（純粋なロジック、I/Oなし、定数）、Medium（実際のDB/プロセス、疎結合）、Large（フルスタック）。Smallを多く、Mediumをやや少なく、Largeを最も少なく。失われがちな中間層 — サーバー/アプリロジックがユニットテストでも結合テストでもカバーされず、各レイヤーが相手がテストするだろうと想定している部分に注意してください。
-
フレーキーテストは発見次第隔離する。 コード変更なしでパスしたり失敗したりするテストは、スイート全体への信頼を損なう。即座に隔離し（ブロッキングゲートから外し、修正のチケットを発行する） — 断続的に失敗するまま放置せず、無言で削除しない。Smallテストは決定論的でなければなりません。実際のクロック、ランダム性、ネットワークを使用してはいけません。
-
テストコードはDAMPであれ、DRYであってはならない。 重複排除よりも説明的で意味のあるフレーズを優先する。テストは単独で読んで明白でなければなりません。テストにDRYを適用することは美徳ではなく違反です（
change-hygiene-and-code-craftを参照）。
よくある言い訳
| 言い訳 | 現実 |
|---|---|
| 「コードを先に書いて、あとでテストを追加する」 | その場合、テストはコードに合わせて調整され、要件に合わせられていない。テストが失敗するのを見ていないので、それが何かをテストしているかどうかわからない。 |
| 「ただのリネームだからテストは不要」 | 正しい — もし名前が内部のものであれば。エクスポート/公開されている場合、名前は契約であり、リネームは振る舞い変更である。 |
| 「リネームしたら3つのテストを修正しなければならなかった、普通だ」 | 違う。契約境界を越えたか、それらのテストが実装の詳細に結合していたかのどちらか。再分類せよ。 |
| 「テストが今は間違っているから、更新するだけ」 | 要件が変わった場合のみ可能。リファクタリング中なら、テストは実際の変更を捕捉した — 調査せよ。 |
| 「ハッピーパスをテストしたから十分だ」 | 拒否ケースもテストされるまでは、ルールはテストされたことにならない。 |
| 「このdenyテストが通るようになった、素晴らしい、出荷しよう」 | 禁止されたアクションが成功することは、進歩ではなくセキュリティリグレッションである。 |
| 「テストがフレーキーだから、CIを再実行しよう」 | フレーキネスは実際のバグを隠し、全員が失敗を無視するように訓練する。隔離して修正せよ。 |
| 「これらのテストをDRYにしよう、共有ヘルパーを使って」 | テストはDAMP。インプレースの明確さに役立つ重複はそのまま残す。 |
レッドフラグ — 停止せよ
- 振る舞い変更の本番コードを、失敗するテストが存在する前に書いている
- 構造変更の差分がtestファイルも変更している
- 公開/エクスポートされた名前を、追加と非推奨化ではなくその場でリネームしている
- リファクタリング中にテストを編集してグリーンにしている
- 拒否ケースのテストがない新しい権限
- なぜ変わったのか理解せずにスナップショット/アサーションを再ベースライン化している
- 実際の
sleep、Date.now()、ランダムデータ、ネットワーク呼び出しを含むテスト - 可読性を犠牲にして重複を排除するためにテストコードをリファクタリングしている
完全な根拠: 憲法第4条、engineering-constitution/references/engineering-constitution.md にバンドル。GraphQL/ルート契約の詳細については graphql-contract-testing を参照。