test

name	test
description	Test code conventions. Modify tests only for genuine spec or architecture changes—never trivialize, skip, or align expected values to a buggy implementation. Avoid implementation branches that depend on specific test data values. Use when writing or modifying test code, or when tests are failing.
user-invocable	false

テスト

テストコードの変更は慎重に行う

テストは仕様を表すものであり、実装の正しさを検証するためのものです。 そのためテストコードを変更する時は、 そのテストが何を保証していて、変更後にも同じ保証が維持されるかを意識してください。

実装にバグがあってテストが失敗している場合は、実装側を修正してください。 「実装の出力に合わせて期待値を書き換える」のは、 テストの意味を失わせる典型的な変更で禁止です。

特に以下のような変更は明確に禁止します。

• アサーションをassert(true)や1 == 1のような恒真式に置き換えてテストを通す
• 失敗するテストをskip/ignore/xfailに変更してパスしたことにする
• 期待値を、実装側のバグを含んだ出力に合わせて書き換える
• 一部のケースだけを抜き出して、エッジケースを暗黙に削除する

判断に迷う場合はユーザーに確認してください。 特にテストの期待値を変更する時は、 仕様の理解が合っているかを事前に確認するのが安全です。

テストコードを変更してよい場合

以下のような場合はテストの変更が妥当です。 変更する時は、なぜその変更が正しいのかをコミットメッセージや差分の説明で明確にしてください。

• テストを追加・修正するタスクとして依頼されている
• テストコードに構文エラーやタイポなど、明らかな誤りがある
• 仕様自体が変わったため、新しい仕様に合わせてテストの期待値や入力を更新する必要がある
• アーキテクチャ変更やリファクタリングで、テスト対象のAPI・モック構造・初期化方法が変わり、 テストを新しい構造に合わせて書き直す必要がある
• 旧仕様の名残で実装と仕様(テスト)の意図が乖離しており、ユーザー確認の上で仕様側(テスト)を更新する

アーキテクチャ変更の際は、 旧テストをそのまま無理に通そうとすると、リファクタリングそのものが歪むことがあります。 新しい構造に合ったテストへ書き直す方が健全な場合は、書き直して構いません。 ただし以下を意識してください。

• 書き直したテストが、新しい仕様の振る舞いを過不足なく表現していること
• カバレッジが意図せず落ちていないこと(エラー系・エッジケースも引き継ぐこと)
• 「リファクタ後の実装の挙動」を写しただけのテストになっていないこと

テストデータに依存した条件分岐は避ける

実装コードがテストで使用されている具体的なデータ値を特別扱いすることは禁止です。 具体的なデータ値とは、テストで使われる変数名やテーブル名などのことです。

データに依存した実装は以下のような問題を引き起こします。

• 脆弱なテスト: テストデータが変更されると実装が機能しなくなる
• 隠れた仕様: 特定のデータ名に対する特別な処理が明示的な仕様ではなく暗黙的になる
• 汎用性の欠如: 実際の運用環境では機能しない可能性がある