フレーキーテストにまつわるあれこれ

フレーキーテストにまつわるあれこれ

※おおむねポエムです。こんなのもあるよ！等あればコメント頂けると嬉しいです！

## フレーキーテストとは

「同じコードでpass/failどちらの結果にもなってしまう」テストの呼び方
flaky=当てにならない、という意味

> [Flaky Testとの戦い Cybozu](https://blog.cybozu.io/entry/2020/12/23/100000)
> Flaky Testとは、実行結果が不安定なテストのことです。 コードを変更していないにもかかわらず、実行するたびにテストが成功したり失敗したり結果が変化するため、原因が追及しにくく非常にやっかいな問題です。

> [Flaky Tests at Google and How We Mitigate Them](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html)
> John Micco氏が所属するGoogleでは、このような「同じコードでpass/failどちらの結果にもなってしまう」テストを、"flaky"(nondeterministicとも呼ばれます)なテスト結果と呼んでいます。
We define a "flaky" test result as a test that exhibits both a passing and a failing result with the same code.
(引用：Google Testing Blog | Flaky Tests at Google and How We Mitigate Them )

## flaky testの出展について

以下が有名

> 【用語解説】John Micco氏の言う"Flaky"なテストとは？ - JaSST東京実行委員ブログ (hatenablog.jp)
> https://jasst-tokyo.hatenablog.jp/entry/2018/02/22/214551
> JaSST'18 Tokyo 基調講演資料 の p.41あたりからflaky testの話が載っている
> http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf

以下により、結構な課題となっている様子

> 発生頻度の多さ（4.2M testsのうち、16%がflaky）
> リリース遅延のリスクに繋がること
> flakyテストを除外するための計算リソースが掛かる
> Flaky Tests
> Test Flakiness is a huge problem
> Flakiness is a test that is observed to both Pass and Fail with the same code
> Almost 16% of our 4.2M tests have some level of flakiness
> Flaky failures frequently block and delay releases
> Developers ignore flaky tests when submitting - sometimes incorrectly
> We spend between 2 and 16% of our compute resources re-running flaky test

retryがflaky testを見付ける手段として重要らしい

> https://docs.cypress.io/guides/dashboard/flaky-test-management
> By enabling test retries, the Cypress Dashboard can detect, flag, and track flaky tests ...

ソフトウェア自動化カンファレンスでも同様テーマで登壇されている@pineapplecandy氏

> E2Eテストのflakyと向き合う / stac2020
> https://speakerdeck.com/pineapplecandy/stac2020

## 世の中にあるCIツールでの対策状況

リンクのみ記載

azure devops

> 不安定なテストの管理
> https://docs.microsoft.com/ja-jp/azure/devops/pipelines/test/flaky-test-management?view=azure-devops

circleCI
> https://circleci.com/blog/reducing-flaky-test-failures/

gitlab Flaky tests
> https://docs.gitlab.com/ee/development/testing_guide/flaky_tests.html

jenkins Flaky Test Handler
> https://plugins.jenkins.io/flaky-test-handler/

githubの事例
> https://github.blog/2020-12-16-reducing-flaky-builds-by-18x/


## 関係する記事 
How to avoid Flaky Tests?

> https://www.browserstack.com/guide/how-to-avoid-flaky-tests Flaky Test Management 
> https://docs.cypress.io/guides/dashboard/flaky-test-management

## 関係する論文 

> Identifying Key Success Factors in Stopping Flaky Tests in Automated REST Service Testing
> http://portal.amelica.org/ameli/jatsRepo/30/308007/html/index.html

## 最低限どこをおさえるのがよいのか

※暫定、適宜更新する

技術面
- 原因分析は必要
- 対策はretry/無視など、原因によって使い分ける
運用面
- 管理できていることが重要、運用データとる場合は統計に現れるようした方がいいかも
- 現場課題のみにならないよう、マネジャーの自動テストの理解度を上げる事も重要

## テスト駆動開発の第一人者`t_wada`さんの資料

> strategy-and-tactics-of-building-automated-testing-culture-into-organization-2020-autumn-edition
> http://jasst.jp/symposium/jasst20niigata/pdf/S1.pdf
> 組織にテストを書く文化を根付かせる戦略と戦術

## フレーキーテストとの戦い方

[FlakyなE2Eテストをリトライで解決する](https://note.com/shift_tech/n/n5f78588f18e3)
[「さよなら Flaky 。不安定なテストの探し方」というお話 2021-04-27](https://blog.cybozu.io/entry/2021/04/27/080000)
[What is ReportPortal?](https://reportportal.io/docs/What-is-ReportPortal?)

## CircleCI 2021年の新機能から見るCI/CDのトレンドにもflakyの文字がある

★ここにflaky testの文字がある！！

> https://event.cloudnativedays.jp/cndt2021/talks/1294
> CircleCI 2021年の新機能から見るCI/CDのトレンド
> circleci issue
>  　機能改善要望
>  　いいね付与で投票することができる
> 開発者体験の向上
>   config.yaml
> データの活用
>   　ワークフロー合計実行回数
>  　　成功率、実行時間、
>   　テストインサイト
> 並列実行によるテスト時間短縮
>  　　実行時間が均一になるように並列化
>  　　テスト実行件数が均一になるように並列化
> テスト結果を分析
>  　　平均テスト実行数
>  　　結果が一定しないテスト（flaky test）　★ここにflaky testの文字がある！！
> 失敗したテスト
>  　　実行時間が長いテスト
>   　ジョブ実行、ワークフロー終了時にwebhook呼び出し
> セキュリティ
>   　　コンプライアンス認定
>    IPアドレスフィルタリング
>   　　ファイアウォール設定
>   　　シークレットのローテーション
> デプロイ
>    https://puppet.com/resources/report/2021-state-of-devops-report

#### freeeの方は自動テストの成功率をrating算出している模様

> https://developers.freee.co.jp/entry/automated-test-structure-2022
> 成功率が下がってきたら安定化施策を実施する
失敗時の原因確認で紹介したように、サービスの変化などにより、自動テストは失敗してしまうことがあります。このようになると、自動テストが失敗した際の原因調査の回数が増えると共に要因が複雑になります。そこで、成功率が下がってきたら、安定して自動テストが実行できるように、テストスクリプトやフレームワーク、サービス実行環境などを修正しています。これをおこなうために、上記のテストの構成で示したように、継続的に実行した結果を収集し、状況を見るようにしています。

#### shitの方々は自動テストの結果をAllre Frameworkにより可視化している模様

> https://note.com/shift_tech/n/naec43294ebd0
> Allure Frameworkとは
自動テストのレポーティングを素敵に見せてくれるレポーティングF/Wです。
> https://docs.qameta.io/allure

# 参考

[Flaky Tests at Google and How We Mitigate Them](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html)
[Flaky Testとの戦い Cybozu](https://blog.cybozu.io/entry/2020/12/23/100000)
[【用語解説】John Micco氏の言う"Flaky"なテストとは？](https://jasst-tokyo.hatenablog.jp/entry/2018/02/22/214551)
[和田卓人さんをお招きして社内講演をやって頂きました！](https://www.ntt-tx.co.jp/column/post/210622/)
[「さよなら Flaky 。不安定なテストの探し方」というお話](https://blog.cybozu.io/entry/2021/04/27/080000)