技術要約：例外的な振る舞い：それらはどの程度の頻度でテストされているのか？

問題提起

例外（Exception）は、発生頻度が低いと予想されるエラーケースを処理するための基本的なプログラミング構成要素であり、過剰な if/else チェックによるコードの煩雑化を避けるために使用されます。既存の研究やベストプラクティスは、高品質なテストスイートは正常系（ハッピーパス）と例外的な振る舞いの両方をカバーして回帰を防ぎ、バグを捕捉すべきであることを示唆していますが、実証的な証拠によれば、開発者は主に正常系の振る舞いをテストしていることが示唆されています。

現在の文献には重大な欠落が存在します。先行研究は、例外がテストレベルまで伝播することを明示的にアサートする（例：assertRaises を使用する）「例外テスト」にほぼ排他的に焦点を当ててきました。これらの研究は、例外がテストへと伝播する前に、コード内で（try/except ブロックを介して）ローカルに捕捉され、処理されるケースを考慮していません。その結果、例外的な振る行為が、テストハーネスに伝播しないものを含め、現実世界のシステムにおいて実際にどの程度実行されているのかは不明なままです。さらに、実行時に例外が発生する頻度（稀な発生から、例外が常態となる振る舞いまで）についても、テストの観点から深く探求されていませんでした。

手法

著者らは、25の現実世界のPythonシステムのテストスイートを分析する実証研究を実施しました。データセットには、人気のあるサードパーティ製ライブラリ（Flask、Requests、Pylintなど）と標準ライブラリのモジュール（email、pathlib、argparseなど）が混在しており、5,372個の実行されたメソッド、1,790万回のメソッド呼び出し、および140万回の発生した例外を網羅しています。

研究では以下の手法を用いました：

1. インストルメンテーション: 著者らは、Pythonの sys.settrace 関数に基づいた動的解析ツールである SpotFlow を利用しました。このツールは、メソッドレベルでの実行を監視するためにテストスイートにインストルメンテーションを施します。
2. データ収集: テスト実行中に、インストルメント化されたシステムは以下を記録しました：
   • どのメソッドが実行されたか。
   • 特定のメソッドが実行時に例外を発生させたかどうか。
   • 各メソッドへの総呼び出し回数。
   • 例外を発生させた呼び出しの回数（例外発生呼び出し）。
3. 分析: 収集されたデータは、異なる粒度に焦点を当てた3つのリサーチクエスチョン（RQ）に答えるために分析されました：
   • RQ1 (メソッドレベル): 実行時に例外を発生させるメソッドはどのくらいあるか？
   • RQ2 (コールレベル): 例外を発生させるメソッドへの呼び出しは、実際にどの程度の頻度で例外につながっているか？
   • RQ3 (システムレベル): 例外を発生させるメソッドおよび呼び出しは、異なるシステム間でどのように変化するか？

主要な結果

RQ1: 例外発生メソッドの普及度

• 実行されたメソッドの 21.4%（5,372個中1,150個）が、テスト実行中に少なくとも1つの例外を発生させました。
• 残りの 78.6% は例外のないメソッドでした。
• 例外を発生させるメソッドは、例外のないメソッドよりも複雑であり、より集中的に実行されていました。中央値において、例外を発生させるメソッドは、例外のないメソッドよりも 4倍多くの呼び出し を受け、3倍多くのパス を実行していました。
• 本研究では 200種類の異なる例外型 が特定されました。その多くは汎用的なもの（例：ValueError、TypeError）でしたが、特定の例外は単一のメソッドによって発生する場合が多く見られました。

RQ2: 例外発生の頻度

• 例外を発生させるメソッドにおいて、例外発生呼び出しの中央値の頻度は 10%（10回の呼び出しにつき1回）でした。
• 例外発生頻度の分布は、高度に偏っています：
  • 稀 (≤10%): 例外を発生させるメソッドの50%がここに該当します。
  • 時折発生 (>10% ～ ≤50%): 28.4%のメソッド。
  • 頻繁に発生 (>50% ～ <90%): 9.6%のメソッド。
  • ほぼ常に発生 (≥90%): 11.8%のメソッド。
• 観察: 例外を発生させるメソッドの**約80%**は、例外を稀に発生させます。しかし、かなりの少数派（約20%）は頻繁に例外を発生させており、特定のPylintのメソッドなどのケースでは、例外を発生させることが「通常」または「期待される」振る舞い（100%の呼び出しで発生）となっています。

RQ3: システムによる差異

• 25システム中22システムにおいて、例外を発生させるメソッドよりも例外のないメソッドの方が多いことが分かりました。
• 25システム中19システムにおいて、メソッドあたりの例外発生呼び出しの中央値の割合は 30%未満 でした。
• システム間には大きな差異があります。例えば、csv ライブラリは53.3%の例外発生メソッドを持っていましたが、Error Corrector はわずか5.6%でした。

意義と示唆

本論文は、ローカルで処理される例外を無視しているため、現在の例外的な振る舞いの理解は不完全であると主張しています。研究結果は、例外の発生が常に「異常」または「稀な」イベントであるという仮定に疑問を投げかけています。

著者らは、研究者および実務家に対して以下の3つの主要な示唆を提案しています。

1. 新しいテストツールの開発:
   ほとんどの例外発生メソッドは、実行頻度が低い（多くの場合10%未満）ため、既存のテストスイートではエラーハンドリングコードの多くが未テストのままになっている可能性があります。著者らは、例外が発生し、かつそれがローカルで捕捉されてテストへと伝播しないケースも含め、例外的なケースをカバーするテストを特定できるツールの開発を提案しています。このようなツールは、エラーハンドリングロジックにおけるカバレッジの欠如を開発者に警告することができます。

2. 「異常な」振る舞いの再評価:
   本研究は、例外の発生が必ずしも「異常」ではないことを強調しています。特定のメソッド（「ほぼ常に発生」のカテゴリーにあるものなど）においては、例外を発生させることは標準的な制御フローの一部です。例外的な振る舞いのテストに取り組む研究者は、例外が発生することがバグやエッジケースを示すメソッドと、例外の発生が期待される結果であるメソッドを区別しなければなりません。この区別を怠ると、テストの品質やバグ検出に関する誤った評価につながる可能性があります。

3. コストの高い try/except ブロックのリファクタリング:
   Pythonにおいて、EAFP（Easier to Ask for Forgiveness than Permission：許可を求めるより許しを請う方が容易）というコーディングスタイルは、しばしば try/except ブロックを導きます。これは例外が稀な場合には効率的ですが、例外を捕捉することは計算コストがかかります。本研究は、例外を頻繁に発生させるメソッド（例：90%以上の呼び出しで KeyError や AttributeError が発生するもの）を、リファクタリングの強力な候補として特定しています。これらを明示的なチェック（例：if key in dict）に置き換えることで、パフォーマンスを大幅に向上させることができます。

結論

本実証研究は、伝播する例外とローカルで処理される例外の両方を考慮に入れ、現実世界のPythonシステムにおいて例外的な振る舞いがどの程度の頻度でテストされているかについて、初の包括的な視点を提供します。結果は、ほとんどの例外発生メソッドは低頻度で実行されるものの、コードベースの非自明な部分が例外を頻繁な制御メカニズムとして利用していることを示しています。著者らは、これらの振る舞いをテストするためのより優れたツールが必要であること、また、例外が頻繁に発生するコードパターンにおいてパフォーマンスの最適化が可能であることを結論付けています。