フレイキーテスト問題
「なんか通らん(くなった)」問題
思っているよりも身近みたいだなsta.icon
7テストに1つはフレイキーなんだとか
いくつかパターンがあるみたい
メモリ使用量との相関がある
時刻。特に月始めなど境界周り
global state使ってる(特に結合した後のテストで起きがち)
局所的である
フレイキーが出るところは偏る
色んな会社が色んな対策してるけど、まとめるとざっとこう
1: all green目指すのは維持しろ
2: frakyを定量的に測れ
3: 起きたfrakyは開発者にエスカレしろ
基本戦略はリトライ
が、githubやdropboxはリトライ時に時刻変える仕組みつくってるみたいだね
GitHubとDropboxでは、VMとかコンテナを使ってシステムクロックを別な時間に強制設定して走らせることをしているそうです
いちいちパイプライン止めるマンがいる
隠すという事に心理的な抵抗が発生して、リトライみたいな手法を使いたくないと思う人たちがいる。そういう人はフレイキーネスでテストに失敗したら、そこでエラーが起きたことにしてパイプラインを止めてしまう。
無視するという戦略もある
例えばDropboxやGoogleがやっていたプリマージ(開発者に近い一番頻繁に実行されるテスト)という手法では、フレイキーネスのせいで起こった失敗であればスルーする。つまり、開発者の間近ではフレイキーネスでテストが失敗してもマージは許すということです。
意外と理にかなっているようだsta.icon
が、次の「計測する」をしてないと、軋轢が生まれる
だから新しくチームに加わった人なんかは、テストが失敗したと思ったらシニアエンジニアみたいな人から、そこのテストの失敗は気にしなくていいよって言われて、いやそんなの知るかと、そういうことが起こる。
一歩進んだ計測の取り組み
Google「何回も実行してたまに失敗したら、フレイキーだとみなそうぜ」
ベースラインを定義する
Spotify「複数のテスト実行してるときにまとめて失敗してる部分があったら、そこはフレイキーじゃねえよな(フレイキーはアトランダムだもの)」
Facebook「テストに問題があってしくじるケースと本当にフレイキーネスがあってしくじるケースがあるよね。この2変数を数学で確率的に予測するアプローチを使えばいいんじゃね」
計測後
GitHub「各フレイキーがどれだけ被害あるのかを定量化して判断の参考にする」
フレイキーネスのせいで2753のビルドに影響があり、140人が迷惑した、ということが書いてあるんです。
Dropbox「実行されたテストを結果に応じて状態に分類してるよ」
https://gyazo.com/8ac114110522c845432c494962b19761
最初はヘルシー。しくったらノイジーにして、ノイジーになったテストは時刻など条件変えて再実行される。でそれで通ったならフレイキーだとみなしてヘルシーに戻すが、通らなかったら隔離する。
モバイルアプリの開発をしている方は分かると思いますが、フレイキーネスがどうしても入りやすい。外部のシステムに依存したりするから。
AirBnB「フレイキーネスはフレームワーク次第。だからちゃんとしたフレームワークを俺達でつくったぜ」
今後起きうる流れ