グーグルのクラウドを支えるテクノロジー > 第79回 CI環境のテストを安全に効率化するアルゴリズム(パート2
- 編集部の見解や意向と異なる内容の場合があります
- 編集部は内容について正確性を保証できません
- 画像が表示されない場合、編集部では対応できません
- 内容の追加・修正も編集部では対応できません
CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー > 第79回 CI環境のテストを安全に効率化するアルゴリズム(パート2)」を公開しました。
###
はじめに
前回に続いて、2019年に公開された論文「Assessing Transition-based Test Selection Algorithms at Google」を紹介します。今回は、Flaky(不安定な)テストの影響、そして、実際のアルゴリズムの評価結果を紹介します。
Flaky(不安定な)テストの影響
前回は、テストデータの構成とアルゴリズムの評価方法の概要を説明しました。まず、テストデータについては、前回の図1のように、安全にスキップできるテスト(「Safe」フラグがついたもの)とスキップしてはいけないテスト(「Unsafe/Maybe Unsafe」フラグがついたもの)がありました。そして、それぞれのコミットに含まれるテストの中で、安全にスキップできるもの、すなわち、Safeフラグがついたものを発見するアルゴリズムについて、その性能を評価していきます。この際、前回の図2のように、すべてのコミットの中で、「Safeフラグがついたテストだけをスキップしたコミット」の割合を計算するわけですが、ここで言う「すべてのコミット」の範囲を明確にする必要があります。
この際に問題なるのが「Flakyテスト」と呼ばれる不安定なテストの影響です。テストターゲットの中には、関連するコードを変更していないにも関わらず、タイミングによって、成功したり失敗したりするテストがあります。これは、テスト内容そのものに問題があるか、もしくは、コード以外の部分に失敗の原因があるものですので、コード変更のコミットごとにテストしても意味がありません。前述のテストデータの中には、このような不安定なテスト(Flakyテスト)が含まれており、これは、アルゴリズム評価の際に余計なノイズとなります。
この続きは以下をご覧ください
https://www.school.ctc-g.co.jp/columns/nakai2/nakai279.html
ソーシャルもやってます!