【ITニュース解説】Same-Session Tests Are Not Evidence. Isolate the Oracle.

ニュース記事は、ソフトウェア開発におけるテストの信頼性を高めるための重要な考え方を提示している。多くの開発現場では、プログラマーがコードの変更と、その変更を検証するテストコードを同時に作成することが一般的だ。しかし、この記事は、この方法には根本的な問題が潜んでいると指摘する。それは、「同じセッションで作られたテストは、真の証拠にはなり得ない」という点だ。

具体的には、開発者がコードを修正し、それに合わせてテストも作成または修正すると、そのテストは「開発者が意図した通りにコードが動くか」を確認するツールになってしまう可能性がある。しかし、本当に確認すべきは「チケット（要件定義書）に書かれた機能が、期待通りに、そして誤動作なく実現されているか」であるはずだ。もしテストが開発者の意図に合わせて調整されてしまうと、たとえすべてのテストが成功して「合格（グリーン）」になったとしても、それはコードとテストの間で「合意」が取れているだけであって、その合意が「本来の要件」とずれているかもしれないのだ。これは「契約がチェックされていない」状態であり、見かけ上の成功に過ぎない場合がある。

このような問題を防ぐため、記事では「オラクルを隔離する」という戦略を提案している。「オラクル」とは、この文脈では「正しい挙動を判断するための真実の基準」を意味する。つまり、コードの変更とは独立した、客観的で信頼できる基準（オラクル）に基づいてテストを行うべきだという考え方だ。これを実現するために、「三つのレーン」と呼ばれる具体的なワークフローが提案されている。

一つ目のレーン（Lane A）は「要件から独立したプロパティ（spec-isolated properties）」の作成だ。これは、開発者が書いた実際のコードやその変更内容を一切見ずに、チケットに記載された要件や公開されているデータ型情報のみから、システムが満たすべき振る舞い（プロパティ）を定義するというものだ。たとえば、「ユーザーIDは空であってはならない」という要件があれば、「有効なユーザーIDを受け入れるケース」と「空のユーザーIDを拒否するケース」という、二種類のプロパティ（検証項目）を作成する。特に重要なのは、拒否するケースも必ず定義することだ。このプロパティは、開発中のコードとは完全に独立した環境で作成され、開発者は自分のコードを、この定義されたプロパティに「適合する」ためのごく薄い「アダプター」を通して接続するだけだ。アダプターには、直接的な検証（assert）コードを書いてはならない。これにより、テストが開発者の意図に影響されることなく、要件に忠実な検証が可能になる。

二つ目のレーン（Lane B）は「開発者が所有しないフィクスチャ（content-addressed fixtures）」の管理だ。フィクスチャとは、テストを実行するために必要な準備データのこと。多くの場合、フィクスチャはテストコードの近くに置かれ、コードの変更に合わせて開発者が修正してしまうことがある。しかし、これではフィクスチャもまた、コード変更の意図に合わせてしまい、独立した検証データとはならない。Lane Bでは、フィクスチャを専用の場所に保管し、その内容のハッシュ値（ファイルのユニークな識別子）をロックファイルに記録して厳重に管理する。開発者がコード変更とともにこのロックファイルを更新することは許されない。フィクスチャの変更は、そのスキーマ（データの構造定義）に基づいて正当性が検証され、人間のレビューを経てから、別のコミットとして行われるべきだ。これにより、テストデータが勝手に変更されたり、意図しない形で書き換えられたりするのを防ぎ、常に一貫性のある基準でコードを評価できるようになる。

三つ目のレーン（Lane C）は「スキップ予算（skip budget）の導入」だ。これは、テストが失敗した場合に、開発者がそのテストを安易にスキップ（無視）したり、xfail（失敗を許容する）マークを付けたり、テスト名を変更して回避したりする行為を抑制するための仕組みだ。テストの失敗はバグや設計上の問題を示唆しているが、それを修正するよりも、テストを一時的に無効化する方が手軽なため、多くのプロジェクトでスキップされるテストが増えがちだ。Lane Cでは、コードの変更差分（diff）をチェックし、既存のスキップマークが追加されたり、スキップを意味するような変更（例えば、テスト本体をコメントアウトするなど）が行われたりした場合に、その変更を拒否する。これにより、開発者はテストの失敗から目を背けることなく、根本的な問題解決に取り組むことを強制される。

これらの三つのレーンを組み合わせたワークフローと、継続的インテグレーション（CI）パイプラインでの実行順序も提案されている。まず、チケットの内容をハッシュ化して固定し、要件が途中で変更されていないことを保証する。次に、コード変更とは完全に隔離された環境でLane AのプロパティとLane Bのフィクスチャスキーマを作成し、コミットする。その後、実装担当者は、この独立したプロパティに適合するようにコードとテストのアダプターを記述する。CIでは、最初にスキップ予算のチェックを行い、次にフィクスチャロックとスキーマ検証、最後にLane Aで定義されたプロパティテストを実行する。この実行順序が重要であり、例えばスキップによってプロパティテストが隠蔽されないようにする。もしプロパティテストが失敗した場合、開発者はコードを修正する必要があるが、失敗したテストケースに合わせてLane Aのプロパティ自体を修正してはならない。それは再び、コードとテストが「同じセッション」で共謀してしまう問題を引き起こすからだ。

このアプローチは、テストの信頼性を大幅に向上させるが、万能ではないという注意点も示されている。例えば、レビュー担当者が誤って失敗したテストのスタックトレースをオラクル作成セッションに持ち込んでしまうなど、人間側の運用ミスによって隔離が破られる可能性もある。また、「より良い請求システムを作る」といった漠然とした要件からは、具体的な「受け入れ・拒否」プロパティを導き出すことは難しい。そのような場合は、まず要件自体を明確化する必要がある。セキュリティや負荷テスト、ライセンスコンプライアンスの確認など、この手法ではカバーできない範囲も当然ある。

この記事が提唱する「オラクルを隔離する」という考え方は、開発者とテストの間に意図的な「壁」を作ることで、テストが本当にシステムの要件を満たしているかを客観的に評価する仕組みである。これにより、見せかけのテスト合格ではなく、真に信頼できるソフトウェア品質の確保を目指すのだ。