Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
本論文は、単一のプロダクションメソッドの複数の実行パスをカバーしているテストを特定する「Test Obsessed by Method」と呼ばれる新しいテストスメルを提案し、Python標準ライブラリを用いた実証研究を通じて、そのようなテストがしばしば複数の振る舞いを検証しており、より焦点を絞ったユニットへとリファクタリング可能であることを検証する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたは、美食家（フードクリティック）のためにテイスティングメニューを用意しているシェフだと想像してください。素晴らしい料理の黄金律は、**「一つの皿には、一つの明確な味だけを出す」**ことです。もし、ステーキ、一切れのケーキ、そして一スクープのアイスクリームを混ぜ合わせた、ぐちゃぐちゃな一皿を提供したとしたら、批評家は混乱してしまいます。ステーキが焼きすぎなのか、ケーキが甘すぎるのか、それともアイスクリームが溶けているのか、判断がつかなくなるからです。何かが失敗したとき、彼らは食事のどの部分を責めるべきか分からなくなります。
ソフトウェアの世界では、「料理」はテストであり、「味」は振る舞い（ソフトウェアが本来行うべきこと）です。
『Test Behaviors, Not Methods!（メソッドではなく、テストの振る舞いをテストせよ！）』と題されたこの論文は、現在の多くのソフトウェアテストが、そのぐちゃぐちゃに混ざった一皿のように提供されていると主張しています。著者である Andre Hora と Andy Zaidman は、このような混乱を招くテストを見つけ出すための新しい方法を提示しており、それを 「メソッドに執着されたテスト（Tests Obsessed by Methods）」 と呼んでいます。
以下は、シンプルな比喩を用いた彼らの発見の解説です。
1. 古いやり方：材料の数を数える
以前、専門家たちは、テストがコードに何回「触れた」かを単純に数えることで、これらの乱れたテストを見つけようとしていました。「もしテストがプロダクションコードを3回以上呼び出していたら、それは多くのことをやりすぎているのだろう」と考えたのです。
著者らはこれを 「熱心すぎるテスト（Eager Test）」 という臭い（smell）と呼んでいます。しかし、彼らはこの手法が、食事を味わうために使われたスプーンの数を数えて料理を判断しようとするようなものであり、不正確であることを見出しました。テストは、異なる「味」をテストするためではなく、単に場面を設定するために何度も関数を呼び出している場合があるからです。これは問題を特定するための、ぎこちない方法です。
2. 新しいアイデア：映画を観る（ランタイム解析）
単にスプーンの数を数えるのではなく、著者らはテストが進行する様子を「映画を観る」ように見ることを提案しています。彼らは新しいルールを提唱しました。「もし一つのテストが、ゴールに到達するために、一つのコードに対して複数の異なる『道（パス）』を強制する場合、そのテストは『執着』している」 というルールです。
プロダクションメソッド（コードの一片）を迷路だと考えてください。
- 優れたテスト： あなたは一人の探索者を迷路に送り込み、左のドアが機能するかを確認します。次に、別の探索者を送り込み、右のドアが機能するかを確認します。明確で、集中しています。
- 執着したテスト： あなたは一人の探索者を送り込み、その探索者が左のドアを通って進み、その後、引き返して右のドアを通り、さらに秘密のトンネルまで試す、ということを一度に行わせます。
著者らはこれを 「メソッドに執着されたテスト（Test Obsessed by Method）」 と呼んでいます。このテストは、一つの迷路のあらゆる経路を一度にカバーしようとするため、「強欲」なのです。
3. 実験：Pythonライブラリの調査
この「執着」が本当に問題であるかどうかを確認するために、著者らは Python Standard Library（何百万もの開発者が使用する、あらかじめ書かれたコードの膨大な集合体）の中をスカベンジャーハント（宝探し）しました。
彼らは 2,054個のテスト を調査しました。結果は以下の通りです。
- 調査の結果： 単一の関数の異なる複数の結果を一度にチェックしようとしている「執着した」テストを 44個 発見しました。
- 広がり： これらの乱れたテストは、チェックした12個のライブラリのうち 11個 で見つかりました。これは珍しい不具合ではなく、一般的な習慣です。
- 修正方法： 平均して、これら44個の乱れたテストは、実際には二つの異なる仕事をしようとしていました。もしこれらを分割すれば、これら44個のテストは、118個 のクリーンで集中したテストに変わっていたはずです。
- 「アハ体験」： これらの乱れたテストの約 23% において、プログラマーは実際に「おい、ここでは二つの異なることをテストしているぞ！」という旨のコメントを書いていました。彼らはそれが乱れていることを知りながら、あえてそうしていたのです。
4. なぜこれが重要なのか？
著者らは、テストが一度に多くの経路をカバーしようとすると、以下のような問題が生じると主張しています。
- 理解が難しい： 先ほどの混ざった皿のように、どの味を味わっているのか判別できません。
- 脆弱である： もし「左のドア」に関するコードを変更した場合、たとえそれらが無関係であっても、誤って「右のドア」のテストを壊してしまう可能性があります。
- 修正が困難である： テストが失敗したとき、具体的にどの振る舞いが壊れたのかが分かりません。
結論
この論文は、あらゆるテストの問題を解決すると主張しているわけではありません。代わりに、単に数を数えるのではなく、ランタイム解析を用いることで、一つのコードに対して多くのことをやりすぎているテストを見つけ出す、より鋭いツールを提供しています。
彼らは、もし一つのテストが関数に複数の異なる経路を強制するのであれば、そのテストを分割すべきであると示唆しています。シェフがステーキ、ケーキ、アイスクリームを別々の皿に盛り付けるべきであるのと同様に、開発者はあらゆる明確な振る舞いに対して、別々のテストを書くべきなのです。
要するに： テストに対して強欲にならないでください。一つの振る舞い、一つの経路、一度に一つの味をテストしましょう。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。