principle-test-behavior-not-implementation

実装ではなく振る舞いをテストする

テストとは、コードが利用者、つまり呼び出し元、エンドユーザー、別のサービスに対して何をするかを示す主張です。振る舞いとは、利用者が使うインターフェースを通じて観察できることです。戻り値、エラー、読み戻せる状態、コードの外部にあるシステムへの影響（送信されたリクエスト、書き込まれた行、発行されたメッセージなど）が含まれます。実装とは、利用者には観察できないことです。プライベートなヘルパー、内部での呼び出し順序、中間データ、どの内部協力オブジェクトが処理を行ったかなどです。

それぞれのテストを、次の2つの変更を想定して評価してください。

• 振る舞いを壊す。 コードが誤った値を返す、処理を省略する、または処理を2回実行するようにします。それでもテストが通るなら、何も証明していません。よくある原因は、契約よりも緩いアサーション、テスト対象のコードで計算した期待値、定数やプロンプト文字列を言い換えただけで、それを読み取るコードを実行しないこと、そしてテスト自身が作成したデータに対するアサーションです。
• 内部を変更する。 観察可能な結果はすべて同じまま、内部のコードを再構成します。ここでテストが失敗するなら、実装に依存しています。リファクタリングのたびに書き直す必要があるうえ、バグを検出できません。

最初の変更を検出し、2つ目の変更には耐えるテストを残してください。それ以外は書き直すか削除してください。両方を満たすテストを書くには、具体的な入力を使い、利用者のインターフェースを通じてコードを実行します。期待値はコードの実行結果ではなく、要件から導き出してください。契約が約束することを、過不足なくアサートしてください。

判断基準はアサーションの形ではなく、契約です。「空のカートには決して請求しない」という約束がある場合、決済クライアントが呼び出されなかったことをアサートするのは振る舞いです。そのテストが呼び出しを検出できることを示すため、請求が発生するケースも組み合わせてください。モックした外部サービスが受け取るペイロードは、そのサービスが観察するため、振る舞いです。内部ヘルパーの呼び出しは利用者には見えないため、実装です。該当するレコードがない場合は空のリストが厳密な答えですが、テストで単に何らかの結果を確認したいだけなら、空のリストを要求するのは無意味なチェックです。呼び出し元が参照しない正確なエラーメッセージを固定すると、文言に依存します。呼び出し元が分岐処理に使うエラーの型こそが契約です。

テストでは、呼び出しではなく不変条件を固定することもできます。たとえば、2つのテーブルに存在しなければならないキーや、コンパイル時の型チェックなどです。その不変条件が振る舞いです。

本番環境での前提条件。 受け入れテストが、本番では決して確立されない状態や順序をセットアップで作り出すことで通るようにしてはいけません。実際の初期化経路を実行するか、呼び出し元がその前提条件を満たすことを証明してください。実際の呼び出し元が指定できる通常のフィクスチャ入力は有効です。

表記であり、ランタイムではありません。 Given、When、Then または Gherkin 形式のテストは、プロジェクトで既に使われているフレームワークで記述してください。プロジェクトが既に使用している場合、またはユーザーが Cucumber、ランナー、.feature ファイルを明示的に求めている場合を除き、Cucumber、Gherkin ランナー、.feature ファイルを追加しないでください。Gherkin 形式のテストを求める依頼は、それらを求める依頼には該当しません。