第105条
テストオラクル問題
テストが誤った答えを捕まえられるのは、コードとは別に正しい答えを知っているものがあるときだけだ。そして多くのプログラムには、それがない。
心得
通ったテストは、何と照合したかを問う
どうするか
大事なものを守るテストは、期待値の出どころを言えるようにする。仕様、手計算、独立した別実装、その分野の専門家などだ。現在の出力をそのまま期待値にしたスナップショットテストや生成テストは、変化の検知器として扱い、コードが正しい証拠とはみなさない。オラクルがないところでは、どのみち成り立つはずのことを確かめる。不変条件、往復変換、関連する入力どうしの出力の関係などだ。監視の整った取り消せる変更なら、カナリアを確認手段にしてよい。手で作るオラクルは、取り消しが高くつく変更のためにとっておく。
なぜ起きるか
Elaine Weyuker は「プログラムのテストでよく持ち出される前提は、オラクルがあるというものだ」と指摘した。テストする人か何らかの仕組みが、出力が正しいかどうかを判定できるという前提だ。オラクルが存在しないか、出力の確認にテストする人が途方もない時間をかけなければならないなら、そのプログラムはテストできない。正しい答えを誰も言えないとき、テストの期待値はコードを動かした結果から取られやすい。そうなると、テストが記録するのはコードがすべきことではなく、コードがしていることになり、書いた時点ですでにあったバグはすべて通してしまう。実装から生成したテストは、とくにこうなりやすい。Chen、Cheung、Yiu は Weyuker を踏まえて「テストオラクルが手に入ることは、たいていの状況で現実的に望めない」と書き、メタモーフィックテストを提案した。通ったテストから次の入力を作り、出力どうしが満たすべき関係を満たしているかを確かめる。これならオラクルは要らない。
当てはまらなくなるとき
本番を判定役にする：安くて取り消せる変更なら、一部に期間を限って出し、実際のトラフィックと SLO に照らして見るほうが、テストを書く人が思いつかなかった問題を拾える。
出典
Elaine J. Weyuker『On Testing Non-Testable Programs』(The Computer Journal, 1982)。"A frequently invoked assumption in program testing is that there is an oracle" と、オラクルがないか確認に途方もない時間がかかるプログラムをテスト不能とする定義の出典。T. Y. Chen, S. C. Cheung & S. M. Yiu『Metamorphic Testing: A New Approach for Generating Next Test Cases』(Technical Report HKUST-CS98-01, Hong Kong University of Science and Technology, 1998)。"the availability of test oracles is pragmatically unattainable in most situations" と、オラクルの要らないテストの出典。対抗原理は Alec Warner & Štěpán Davidovič「Canarying Releases」『The Site Reliability Workbook』(O'Reilly, 2018) から。カナリアを "a partial and time-limited deployment of a change in a service and its evaluation" とする定義の出典。
原典を読む引用するとき
Hammurabi『第105条 テストオラクル問題』 https://kanywst.github.io/hammurabi/ja/laws/test-oracle-problem/
BibTeX
@misc{hammurabi-test-oracle-problem,
title = {テストオラクル問題},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 105},
url = {https://kanywst.github.io/hammurabi/ja/laws/test-oracle-problem/}
}コラムで読む
- AI がコードを書くとき コラムの次：カーニハンの法則