2022/06/06 01:01
tengo1985
とくに後編がめちゃくちゃおもしろいな。あえてシステマチックに無視するというのはたしかに抵抗あるけど合理的なんだろうな。テスト削る決断もできないことが多い。
2022/06/06 05:18
rryu
なぜか時々失敗するみたいな再現条件が難しすぎるやつだが、少しでも傾向を掴もうとする研究が涙ぐましい。
2022/06/06 05:33
kkobayashi
単なるcorner caseじゃないの？フレイキーだろうがバグはバグやろって気がするけど。。
2022/06/06 05:54
maghrib
“≫後編に続く。後編ではフレイキーネスを受け入れつつソフトウェアデリバリーパイプラインをちゃんと動かしていくこと、フレイキーネスを計測すること、そしてフレイキーネスを開発にフィードバックすることの3つ
2022/06/06 06:10
circled
LinusがIntelにブチ切れてたECCメモリが無くなったせいだと思う。(テスト安定しない)
2022/06/06 06:17
typex2
長いけどじっくり読みたい記事。
2022/06/06 06:25
nakamura-kenichi
色々寄せ集めを使い過ぎなんやで。全部自前で組んだらフランキーだのは起こらんやで。
2022/06/06 06:44
ken39arg
時間に関わる問題でテストケースの実行中に秒を跨いだ時にエラーになるというのが80%を占めていると思ってる。それ以外はほぼマジで原因がわからないやつ
2022/06/06 06:57
eagleyama
“要するにフレイキーなテストっていうのは、本当はコードには問題がないんだけどテストが失敗するっていうことだから、火事が起きてないのに鳴る非常ベルみたいな、そういうことかなって”
2022/06/06 07:12
rna
メモリ使用量との相関って結局どんな因果でテスト失敗に繋がってるんだろ。
2022/06/06 07:15
kamei_rio
宇宙線かな？と思ったら本当に原因不明で失敗することがあるテストについての話をしている
2022/06/06 07:38
masatomo-m
並列プロセスでテストを回してると別プロセスと通信する部分やOS呼び出し周り（主にファイルシステムアクセス系）で起こりがち。大半はリソース競合と時刻周りかなあ
2022/06/06 07:43
getcha
ちゃんとバグの無いコード書け。っていいたくなった。できる事変わってないけど、複雑な理論やアーキテクチャーがもてはやされクオリティも下がってるな。という印象。
2022/06/06 07:44
remonoil
実時間関連のテストはその時のCPU負荷によって失敗したり成功したりする。判定条件ゆるくしとくしかないかなあ
2022/06/06 07:45
sgo2
ありがちな割にあまり認知されて無さそうな事例→++nはアセンブラレベルだと取得/加算/保存の3ステップの処理だから、非同期でn=0とかやっても(n=0が)打ち消される事がある→カウンタが上限を超えたりする
2022/06/06 07:46
xlc
実例をあげないと訳が分からず怪文書にしかなっていない。/ おそらくはテストを正しく書くのが難しくてテストにバグがあるという話。/ 前編は釣り針らしい。
2022/06/06 08:05
H_He_Li_Be
そのテストを修正する以外に解決方法はないのでは、という気がする。記事を読むと、色んな企業が取り組んでるみたいだからそんな単純な話じゃないんだろうけど、問題意識がよくわからなかった。
2022/06/06 08:17
rasterson
計算機は自然現象ではないので、必ず原因はある。以前、メモリーを連続アクセスしたら割り込み発生する基板には参ったが、特定できれば理屈は通った。「原因不明」=「追いかけることを諦めた」ですよね。
2022/06/06 08:29
ext3
ジェンキンスと言われると未だに寿司を思い出す
2022/06/06 08:32
kako-jun
宇宙線とか未知の入力かと思ったけど、マルチスレッドで多いのならlock漏れ？冪等性が時々ないというのも、アノマリーに見える……
2022/06/06 08:57
b_wa
簡単なシステムではフレイキーテストなんて発生しない（時間だって上手くやる方法はある）けど、Googleなどの大規模or高度なシステムでは私の思い付かないようなフレイキーなテストが色々あるのではと思った。
2022/06/06 09:03
tettekete37564
DB の状態依存とか通信経路上の問題とか？/システム全体と書かれているので複雑な結合テストで起こるということかな。
2022/06/06 09:09
sds-page
Ajaxで非同期通信してると上手い事いかないケースが多発した。資金やリソースに余裕ある大会社なら力技で何とかできるかもしれんが予算もリソースも限られてる小さな案件は･･･
2022/06/06 09:10
hiroshe
発生する確率が低くて致命的でなければ、運用始めてから潰す方が楽だよね。
2022/06/06 09:11
Falky
なんも言ってねえに等しい前編。小泉進次郎かと思った
2022/06/06 09:12
junorag
コードかテストに問題が必ずあるみたいなコメントが多いが、名だたる一流の開発チームも苦労しているということから考えるに、そういう原理主義的な議論のフェーズはとっくに越えてる先のお話だと思う。
2022/06/06 09:14
atsuououo
ブコメの方に違和感。Googleみたいな超巨大システムであれば起きてもおかしく無いのでは？？／意味不明と言ってる人はアプリ以外（インフラ）を考慮に入れていないのでは。
2022/06/06 09:14
raimon49
「何故かコケる」テストについて各社の問題解決アプローチ。面白かった。
2022/06/06 09:25
ming_mina
フレイバーテキストに見えた
2022/06/06 09:38
name-25137412
興味深い。あとで何度か読み返す。
2022/06/06 09:46
Kesin
前後編ともに名だたるビッグテックの事例への紹介が充実しているのがありがたい。この手の話はニッチなのでなかなか見つけられないのだよね
2022/06/06 09:48
greenbow
コードやテストに問題がある可能性はあるが、フレイキーテストを減らす方が総合的にはバグを発見しやすい、ということかな。 testing.googleblog.com
2022/06/06 09:49
d0i
自然現象にだって原因はあるし、計算機だって自然現象だよ（HWデバッグしながらコンパイラ開発とかしてるとなにもわからん）
2022/06/06 09:52
qouroquis
智子が妨害している説
2022/06/06 10:04
north_korea
実行時間に依存するテストはどうしてもflakyになりがち。たまたまその時AWSが重かったとかはよくある。環境構築を含むテストだと503エラーとかで依存関係のソフトのインストールに失敗してこけるとか。
2022/06/06 10:05
Magicant
他のブコメ、そもそも問題意識が共有できてなさうなものが散見され、ある意味幸せ者なんだらうなあと
2022/06/06 10:08
tagomoris
Flakyなテストと日常的に戦ったことがあるかで聞く側の理解がぜんぜん違いそうな内容 / ビジネスロジックだけだと意識しなくてもdeterministicにできることが多いから
2022/06/06 10:10
rgfx
テストを「正しく」書く、常に「何を確かめたいのか」に正しくフォーカスできたテストを書くというのは難しいのだなあという顔になる。
2022/06/06 10:11
otihateten3510
確かに後編が面白い。かなり巨大なプロジェクトだね。、
2022/06/06 10:11
iteau
まったく門外漢だけど、コードに問題がないなら、半導体の問題なのではないか。
2022/06/06 10:16
kuenishi
完璧なテストコードを書けばテストはFlakyになりにくいと思っている派（そんなもんがあるならナァ！！！）です
2022/06/06 10:17
PrivateIntMain
たまに怪しい動きしてるやつがいるとして、他の何も問題無いやつのデリバリー止めてまで対処しますとはならない場合もあるし、ただただ後回しにするんじゃなくて後でちゃんと直せるよう監視しようねという話。
2022/06/06 10:34
codehex
TCP Proxy を作ってる時に発生した。結局中継元のデータ読み込みでバッファリングされている時とされてない時があって、されてる時にその分のデータを中継してないせいでテストがこけていた。
2022/06/06 10:40
aceraceae
こういうシンプルなかたちにして考えることが原理的に難しい問題って嫌だなあ。
2022/06/06 10:41
MetaVariable
抽象化されたソフトウェアロジックの誤りではなく、原因究明が難しい計算”機”や環境的な原因で発生するバグの話。テストが正しくても偶発的に発生する誤りと統計的/心理的/組織的にどう向き合うか。（実例は後半）
2022/06/06 10:45
fog-og-frog2
E2Eテストでパラレルに全流しとかして、通常運用でトレードオフと割り切った貧弱リソースへの偏り→実行時間が激重で失敗、とかかな、遭遇したの！metricsをきっちり取ってる体制がこの記事の見どころだよね。
2022/06/06 10:46
nakag0711
レースコンディションなんてマルチスレッドアプリ開発なら当然直すとこ。直すの簡単じゃないがほっとくと後が怖いで。あくまでテストコードの実装の問題でしかないのがハッキリしてるならまあ…
2022/06/06 10:48
katsyoshi
とても面白い。ブコメ読んでるとflakyを軽んじてる人がいて幸せそうだった。
2022/06/06 10:50
dreamzico
/*何もしてないのにエラーになった*/　/*よく分からないけど引数の順番を変えたらなぜか直った　このままいじらないこと*/
2022/06/06 10:58
ancient_tarako
たまに発生する失敗にビビってる奴いる！？いねえよなあ！！(マイキーテスト)
2022/06/06 11:05
manaten
関心事が膨らむほど、テスト時にコントロール不可な領域が広がるのでこういう問題に遭遇し安い印象。結局アプリケーション全体の挙動をテスト全体では担保したいのだから、こういう問題からは逃れられないのだろうな
2022/06/06 11:06
hiby
SONYのCell（PS3）があんま流行んなかった原因みたいなの思い出した。並列スレッド処理、私の苦手な言葉です、みたいな。
2022/06/06 11:12
shoh8
ヒキ強めの読み物だから最後まで読む
2022/06/06 11:12
ardarim
経験的には不再現バグの大半は本文中にもあるけど排他制御ミス（レースコンディション）が多いと思う。後はローレベルだとvolatileかハード起因か。突き詰めると本当に原因不明なのはほとんど無い/後編はこれから読む
2022/06/06 11:17
hdkINO33
“帰り際にコードに変更を入れてビルドとテストを実行したら、テストが通るはずなのに通らない。” この挿話は必要だったのだろうか……
2022/06/06 11:21
sakidatsumono
えらいこっちゃ
2022/06/06 11:33
uunfo
「なぜかテストに失敗する」は実在する
2022/06/06 11:33
field_combat
原因不明のエラーは受け入れつつ、どうするかの話
2022/06/06 11:33
natu3kan
複雑系だから、ある程度は傾向が読めて正しいテストコードが書けたとしても、片っ端からやって確認していくしかないんだよな。原因不明だが特定条件だと絶対に出ない確率的な不具合もあるし。
2022/06/06 11:35
programmablekinoko
宇宙線によるメモリ内容の破壊とかあるんだよな。クロームあたりだと利用者数が多いからぶち当たることがあるらしく、其のためのメモリ走査が走っていると聞いた。あとハードのバグも当然ある
2022/06/06 11:40
jaofeijflisa
テストではないが古いパソコン使ってるとたまに立ち上がらない事があってもう一度電源入れ直すと立ち上がるみたいな感じ？
2022/06/06 11:45
mokepoin
滅多にないけどこれ出たらお手上げ。再現性のないバグは直すことができないのよ。
2022/06/06 11:52
r-west
単にテストか製品(下位層含む)のバグに決まってるんだけど、この話はそういう技術論ではなく、最高レベルの人達がこうしてる＝コスパ悪いバグ調査をうまく蹴飛ばせる所が勝つって、組織論・プロセス論の話か
2022/06/06 12:03
tasato-redhat
K8sのE2EでFlakyテストに悩まされてるのでこれは必読。なんでFlakyが起こるかというと複数のReconcileが絡む非同期的な状況で最終的な状態を検証する必要があるから。そのためのGomegaとかなんだけどそれでも排除できない。
2022/06/06 12:05
mysql8
Cloud Dataflowあるある
2022/06/06 12:08
buhoho
よくわかりませんでした。時刻がとか言ってるしテスト自体が時間とか環境資源を考慮してないってこと？そういったバグのあるテストを抱えたままどうやってビルド(テスト)を継続する？みたいな話ですの
2022/06/06 12:17
tobigitsune
まさにこの記事にある通りの「教条主義的にフレイキーネスは絶対駄目なんだと言って周囲と摩擦を生む」人がブコメに散見されている
2022/06/06 12:30
mangakoji
全くわからん。普通にバグなんじゃないの、それ。落とさないつもりのバグならマスクするべきだよね。難しいのかもわらんが。
2022/06/06 12:31
nilab
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 － Publickey
2022/06/06 12:57
srng
世界の上澄みエンジニアがそれでも悩んでいる話なのに小さいこと言ってるブコメが目立つ。大企業の問題に対して中小企業の論理で訳知り顔で語るみたいな
2022/06/06 13:11
latena
たとえば金融とか医療みたいな領域とエンタメとか教育みたいな領域とを一緒くたにしてフレイキーテストを語ることはできないとおもった
2022/06/06 13:16
Kenju
1日に1回動くバッチが、数年に1回だけエラー停止する。どう調べてもコードに問題はない。そのままの環境でリトライすると正常終了する。すごく厄介。
2022/06/06 13:18
Error401
正しいプロダクトコードに対して（ほぼ）正しいテストコードでテストしたら、大抵はパスするが、なんらかの要因でごくたまに失敗するテストコードが存在するという話。簡単に原因がわかないときにどう対処すべきか？
2022/06/06 13:19
onesplat
超良い発表。FBがベイズ推定で真偽判定してるの面白い / この記事が理解できないとか、ただのバグでしょとか言ってる奴らは、恐らく決定論的で簡単なコードしか書いてないのだろう。ある意味で幸せ者なのかもしれない
2022/06/06 13:20
kamocyc
ユニットテストだけ書いてるレベルじゃなくて、複雑なE2Eテストや複雑な分散システムのテストが大量にある状況で初めて問題になるので、「世界中のITエンジニアが悩まされている」が不正確なのでは？知らんけど
2022/06/06 13:34
cyan0302
バグとテストがこけることを同じ意味で語っている人が多いような...？
2022/06/06 13:34
aktkro
googleでもgithubでも発生してるというところに安心と絶望を感じる
2022/06/06 13:34
asuka0801
Flaky Testに出会った事がないというITエンジニアは要するに固定値でのテストしか経験した事がないんじゃないだろか。Fuzzingでも流せばどんなシステムであろうと何処かしらでエラー吐くよ。
2022/06/06 14:22
NOV1975
「システムとしての挙動は正しいけど、結果を決め打ちして検証するテスト故に場合によっては通らない」ケースの話だよねこれ（バグではない）。まあ結果がバグなのかフレイキーなのかの判断って自動では難しいよね
2022/06/06 14:53
kxkx5150
googleで解決出来ないってなると、すごくスッキリして許容できるようになる。
2022/06/06 14:55
tokumaga
“フレイキーネス”
2022/06/06 15:24
naggg
“テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。”
2022/06/06 15:26
maeda_a
マルチスレッドとか並列プログラムのデバッグって、半世紀ほど前からの未解決問題。「単なるバグ」とか「突き詰めればわかる」とか言ってる人は容易に直列化可能な問題しか解いたこと無いんかも。
2022/06/06 15:59
mn112hr
フレイキーとか言わないで、再現性不定、とか言えば良いのに
2022/06/06 16:14
iga_k
ランダムで失敗するテストに対する川口さんの考察
2022/06/06 16:21
taguch1
偉いエンジニアもはまってる問題だからお前らは黙っとれとかいう人たちは自分のチームでちゃんとコミュニケーション取れてますか。技術も大事だけど伝え方も同じくらい大事
2022/06/06 16:23
queeuq
まじで謎なやつあるんだよなぁ。FWのテスト機能がバグってるのかCIがおかしいのかメモリか静電気化お札か/川口さんのセッションだから海外で英語かと思ったら日本のイベントだったんだ。アーカイブ無いのかな。
2022/06/06 16:37
strawberryhunter
宇宙線によるビット反転というわけでもなさそうなので、原因としてはテストかコードに問題があるけど、観測しつつ無視するという事か。弊社にはまだ高度過ぎるな。
2022/06/06 17:10
stamprally
原因不明、じゃなくて同じコミットなのにテストが通ったり通らなかったりするやつのことな。だいたい非同期な処理か外部依存の何かが悪さしてんだろという印象。特定しづらいだけで原因は必ずある。
2022/06/06 17:51
yoshikidz
むかしCybozuでFlakyTestの話上がってた気がするな。一番最初に自分が遭遇した時めっちゃ地雷踏んだ感が毎回出るwリリースのタイミングだと原因わかるまで焦るし、ネットワーク系とか特定の高負荷環境下だともっと焦る
2022/06/06 18:01
ryan_aircloset
これはほんとに悩ましい。時間とか非同期とか原因が多岐にわたるのもまたつらいところだが、起きてから対処はもちろんテスト作るときにもっと対策を入れたいところ。
2022/06/06 18:17
frontline
この話をスッと通すには受け入れる側に最低限の計算機科学的な知見が必要で、「環境なんてアプリが動くならいつだって一緒っしょ！」とか思ってるチームやリーダーには通じないのでウチで見かけても見ぬ振りしよ……
2022/06/06 18:17
lochtext
ミッションクリティカル系ではそもそもこんなバグが出ない構築にするでしょ
2022/06/06 18:31
zatpek
“フレイキーネスの発生にはいくつかのよくあるパターンがあって”「坂道、四ツ辻、川の側」という感じでワクワクするな。
2022/06/06 19:44
sasashin
業務ロジックの単体テスト書いてるだけだとほぼ関係ないので…。
2022/06/06 22:20
dhrname
正月のモチつきで、つく人Aが「お先にどうぞ」とダイクストラ・メッセージを発して止まると同時に、こねる人Bが「お先にどうぞ」と譲って、Aが先につく。これで、排他制御なしで、「食事する哲学者の問題」を解ける
2022/06/06 22:43
Mofuyuki
計測してフィードバックはtwadaさんもどこかで解説してたなあ。これ読むまですっかり忘れてた。/これこれ。これの1時間あたり。m.youtube.com
2022/06/06 23:04
kazkaz03
「原因不明？テストにバグがあるからに決まってんだろ(キリッ」と言える人が羨ましい
2022/06/06 23:26
harumomo2006
昔ACCESS98から2000への移植をしたとき同じUPDATEを連続で3回実行している時間のかかる処理があったので1回にしたら時々更新できない謎の現象が発生したので3回実行に戻したことがある。それ以降見たことない謎現象
2022/06/07 09:10
tick2tack
フレイキーテスト。テストが原因不明な失敗をする。こういう言葉あるのね。
2022/06/07 11:16
richard_raw
私は単純なプログラムしか書いたことないのでピンと来ませんが、ビッグテックも頭を悩ませている普遍的な問題なんですな。