今日読んだのはこちら。

Shi, August, Wing Lam, Reed Oei, Tao Xie, and Darko Marinov. 2019. “iFixFlakies: A Framework for Automatically Fixing Order-Dependent Flaky Tests.” In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. New York, NY, USA: ACM. https://doi.org/10.1145/3338906.3338925.

読もうと思ったきっかけ、参照していたもの

A Survey of Flaky Tests | ACM Transactions on Software Engineering and Methodologyを先に読み始めて、参照されていたので気になった。

メモ

論文の概要

  • Flakyなテストは一般的に、テストの実行順によってPass/Failが変わる、順序依存のテストである
  • 順序依存のテストを自動的に修正するためのフレームワーク、iFixFlakiesを考案・有効性を調査した
  • 結果、公開データセットに含まれる110の順序依存のテストに対して、58のテストに対してパッチの生成を行い修正案を出せた
    • かつ、平均238秒というかなり現実的な時間で。
  • 58の修正案の、論文執筆時点の状況
    • 2つのテストは修正案を作成時点で修正済
    • 21のテストはプルリクを送ってマージされた
    • 35のテストは送ったプルリクを検討されている段階（しかしリジェクトはされていない）

背景

  • テストがFlakyになる原因のうち、トップ3に入るのが順序依存
    • 開発者が手動で修正する必要がある
    • 自動で修正できると嬉しい

手法

順序依存のテストについて、以下の区分を定義した

  • victim:単独で流すとPassするが、他のテストと特定の順番に実行するとFailする
  • brittle:他のテストと特定の順番で流すとPassするが、単独で流すとFailする

また、これらのFlakyなテストに関係するテストを、以下のように区分した。

  • Polluter:victimがFailする原因をつくる（グローバル変数、ファイルシステム、ネットワークに影響する）テスト
  • Cleaner:Polluterによって変化した状態をリセットし、victimがPassするようになるテスト
  • State-setter:brittleがPassするために実行する必要があるテスト

CleanerとState-setterを合わせてHelperと呼ぶ。

iFixFlakiesはテストの中からHelperを自動で見つけ、これらのコードを利用してパッチを作成する。開発者はパッチを直接Flakyテストに対してインライン化するか、他の方法で取り込むかなどを検討する。

結果

ResearchQuestionは以下

  • RQ1:順序依存のテストについて、iFixFlakiesはどのくらいのvictim, brittle, Polluter, Cleaner, State-setterを見つけるか
    • 用意したデータセットに含まれる順序依存のテスト110のうち、58のテストでパッチを作成
    • victim1つあたりPollerが1.3、など詳細なデータは論文参照
  • RQ2:iFixFlakiesが生成するパッチの特徴は
    • サイズはそれほど大きくなく、平均で元々のステートメントの24.6%
  • RQ3:iFixFlakiesがPolluter, Cleaner, State-setter, パッチを見つけるのにかかる時間は
    • ヘルパーありの順序依存のパッチを作るのに平均238秒、ヘルパー無しの場合は341秒

感想

Flakyテストは順序問題がメイン、というのは「本当か？」と思う部分があるものの、実行順序依存のFlakyテストを一定自動で検出・修正までできるのは興味深かった。

自動修復までいかなくとも、victim, brittleなどの区分自体が有用そう。

次に気になっているもの