https://lists.apache.org/thread/d4r4g9hqfmwpckdk9j01n7dh5y25j11n

背景故事

俗話說的好人在江湖走哪有不埃刀，只有不寫 code 的工程師才能保證不寫出 bugs，作為一個非常多人且龐大的開源專案，Kafka 已經累積了數萬個測試，而其中自然也或多或少有著不穩定的測試，也就是我們今天的主題 Flaky！

沒有工程師喜歡 flaky，對吧？Flaky 本身的存在就是一種警告，它在警告我們的測試可能不準確、警告我們的程式碼可能有 bugs、警告我們的測試環境可能有問題、警告我們注意這次 CI 的結果，因此我們理論上應該用盡全力來修復 flaky 對吧？但如同Google的文章所說，flaky 產生的速度通常跟 flaky 被修正的速度差不多，換言之，這會是一場永無止境的戰爭，而身為打工仔的我們是沒有餘力來打贏這場戰爭，那麼，我們該怎麼辦？

常見處理 flaky 手法自然就是忽視，打錯，retry。沒錯，這就跟你腦袋裡的直覺一樣，如果一次不過那就試第二次，如果第二次不過，那就第三次，如果第三次不過 ... 好吧，我的程式碼有問題我乖乖改，聽起來 retry 好像有點負面，但是如果沒有 retry，我們在每次 CI 的時候，就很可能因為 flaky 而無法得到綠色的勾勾，進而影響我們判斷可否合併，累積久了也會讓我們逐漸對紅色記號無感，因此適當的 retry 其實是可以讓 CI 的過程更加幸福美滿一點

然而然而，retry 久了也同樣會讓我們對 flaky 逐漸習慣，就像是習慣一個渣男婊子一樣，時間久了還是會造成傷害，我們總是有一天要鼓起勇氣離開這個有毒的環境，所以故事就回到我們該用怎樣的機制，來讓大家可以心平氣和的面對 flaky 同時又不影響 CI 的流程？

解決辦法

很不幸的一件事情，除非從此不再加入更多功能，不然我們人類並沒有一個方式可以永遠解決 flaky的發生。所以如果思路放在如何不再產生 flaky 是行不通的，我們能做的就是讓大家更好的注意到 flaky，並且期待大家願意好好處理每隻 PR 產生的 flaky。

附錄

如果在螢幕前的讀者也是使用 gradle 作為開發的話，這裏推薦一個很不錯的服務，稱之為 gradle build scan，它可以收集專案裡建制甚至測試的結果，上傳到 gradle develocity 服務，該服務會幫忙彙整出各種統計結果，例如建制過程中的各種問題、執行時間等等，其中最重要的一個功能就是會整理測試結果，標記哪些測試陸陸續續有失敗有flaky的特徵。讀者們有興趣可以點擊 Gradle Develocity for Kafka 看看那個精美的 flaky，如果有哪個 flaky 看上眼了也可以送個 PR 來修復修復喔

廣告
歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術