https://issues.apache.org/jira/browse/KAFKA-17619

背景故事

今天來聊聊Kafka新的測試框架ClusterTestExtensions，以前Kafka的整合測試是利用繼承的方式來實現，也就是Kafka定義了一個抽象類別並且把整合測試所需要的東西都放在裡面，然後需要整合測試的類別去繼承就能獲得整合測試的能力。聽起來很耳熟對吧，我相信這也是許多人寫整合測試的一種手法。不過呢，這個方法會有一些小小的問題，首先它佔用掉Java世界裡面一個寶貴的繼承，在這個不能多重繼承的世界裡，佔掉那個寶貴名額就形同把我們這些偉大的工程師的手打斷一隻一樣。其二學過物件導向的人都知道一句老梗，「優先使用組合，其次才是繼承」，不論是可讀性或是彈性，我們都應該盡量以組合為優先的考量。這些因素再加上Kafka演進越來越多的東西加入到整合測試的框架裡面，進而導致開始出現各種基於整合測試的各種繼承來繼承去的類別，有時候已經多到我們根本不知道該繼承誰來寫怎樣的測試。因此就在某一天，社群突然大喊一聲，我們都已經在用Junit 5了，不如就用它的框架來重寫我們的整合測試吧？

「對阿，有道理欸」

等等，你心裡是不是在想說什麼狗屁道理，我怎麼一點都沒有感覺到。別怕，我這就來囉唆囉唆，Junit 5有定義一系列的APIs，允許使用者在基於Junit 5的框架下去開發自己的插件，來做到一些客製化的功能，Kafka這裏用到幾個有趣的功能：

1. TestTemplateInvocationContextProvider，這組API允許我們為整合測試建立他們需要的內容，例如這個整合測試需要一個基於KRaft的嵌入式叢集，那麼該測試就可以透過宣告來描述該叢集的樣子TestTemplateInvocationContextProvider會把測試的宣告收集起來後，轉交給實作來產生對應需要的內容。
2. TestTemplateInvocationContext，顧名思義這個界面就是所謂的測試需要的內容，現在的Kafka提供了多樣化的整合測試內容，總共有zookeeper, Kraft, Kraft-combined三種內容，這三種都使用了不同的叢集架構，可以大部分的滿足我們開發整合測試所需要的內容
3. ParameterResolver，這玩意允許我們提供給整合測試需要的元件，例如測試的開發者可以在某個方法上突然大喊一聲，元氣彈，這時候手上就會突然充滿力量，而這種變態的動態注入的功能就是可以透過這套API來完成

等等，為什麼開始介紹起API了，那個很無聊欸，沒錯，真的很無聊，小編寫到都快睡著了。那接下來我們趕快來看看這樣做的好處到底是什麼？首先透過宣告來描述整合測試可以讓程式碼更好閱讀，不會再有各種if-else鑲嵌在裡面，日記般的寫法非常無趣但也簡單好懂。第二實作和介面的隔離，前面提到TestTemplateInvocationContext就是整合測試可以拿到的內容，而ParameterResolver則是讓我們可以注入指定的物件到測試裡，因此一個互相搭配的組合拳又出現了，我們可以在TestTemplateInvocationContext裡面實作各種奇奇怪怪的東西，但當測試的人真的需要物件操作時，我們可以透過ParameterResolver將界面注射進去，如此開發者可以快樂的操作介面不用管後面有多奇怪的內容。

寫了這麼多，是不是該拉回今天的主題了。今天的主題其實來自Kafka要準備移除zookeeper了，所以自然也要從測試框架中把zookeeper的部分刪掉，那這部分會很難嘛？當然不會，就是動動手指頭而已 ...

解決辦法

既然只是動手指頭的工作，那麼解法自然只有一種，那就是悶著頭下去做，直到被人審查被人合併為止都不能停，這就是一種自我考驗和成長的機會，也是一種開源的精神。沒啦，其實我是亂說的，在開源的世界裡面其實是很資本主義的，各種熱門的開源技術背後都有公司，甚至還有各種花式挖角的行為 ... 糟糕，講太多了，下次繼續！

廣告

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