Jan. 11 03:22~04:55
▲圖1：Pitest產生的涵蓋率報表
前言
今年初開始幫ezKanban的use case tests（使用案例的測試案例）改用Given-When-Then的格式讓它更接近Living Documentation，如圖2。改完之後發現use case tests與Aggregate Root測試案例（單元測試）有許多重疊的現象。因為ezKanban的所有Aggregate Root都包含了合約（Contracts），在程式執行期間會自動驗證程式正確性，因此Teddy就在想「是不是可以透過Specification by Example方式所撰寫的驗收案例，加上幫Aggregate撰寫合約，來省略entity layer的單元測試」。
▲圖2：加上Given-When-Then的測試案例
如果這個想法成立，就可以在確保程式正確性的前提之下少寫很多單元測試 。問題是怎麼知道拿掉entity layer的單元測試只要有Aggregate Root的合約依然可以確保程式正確性呢？軟體測試中有一種叫做Mutation testing（變異測試）的方法可以回答這個問題。
***
驗證關卡1
有兩位非常優秀的ezKanban的成員負責驗證這個想法，這個題目並成為其中一位的碩士論文。他們找到Pitest這個Mutation testing工具，但是使用在ezKanban的時候遇到問題一直無法解決。因為這是個最新冒出來的題目，所以還沒有機會在ezKanban團隊的mobbing活動中一起處理，這兩位成員是利用mobbing以外的時間去嘗試解決。
昨天和ezKanban團隊mobbing，上午把這幾周以來一直在處裡的持續整合工作告一段落。盤點一下手邊的工作，團隊決定一起看看Pitest的問題。團隊手邊有一個測試用的小專案，可以正常執行Pitest，但是當團隊在ezKanban的專案中執行Pitest卻會出現如圖3的不明錯誤訊息。
▲圖3：Pitest錯誤不明訊息
由於團隊是透過maven去執行Pitest，因此大家懷疑是不是maven專案的pom.xml檔案設定有問題。於是團隊試著修改pom.xml檔案但問題還是沒解決。後來Teddy想到，既然有一個可以正常執行的專案，那乾脆把ezKanban的程式碼複製到這個專案中看看能不能執行，這樣子就可以確定到底是ezKanban程式碼導致Pitest執行失敗，還是因為maven設定的問題。
將ezKanban程式碼複製過去之後可以正常執行Pitest，於是團隊試著比較兩個專案的pom.xml的差異。大家看來看去也看不出來到底是哪裡有問題，索性將兩個檔案文字比對，如圖四）。
▲圖4：比對兩個專案的pom.xml差異
發現原來ezKanban使用JUnit 5的artifactId是junit-jupiter-api，如下：
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.2</version>
</dependency>
而Pitest只支援JUnit 4，但有鄉民幫它加工之後讓它可以在Junit 5執行，但是此時artifactId要改成junit-jupiter。
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.8.2</version>
<scope>test</scope>
</dependency>
改用正確的依賴之後，Pitest就可以產生如圖1的報表。
***
驗證關卡2
ezKanban系統由若干的maven專案所構成，一開始團隊使用DDDCore這個相依性最簡單，只包含Clean Architecture的Entities Layer與Use Cases Layer，沒有使用到SpringBoot與資料庫的專案來測試Pitest。測試成功之後改用Account專案，這個專案除了包含Clean Architecture中的完整四個Layers，除了使用到SpringBoot與資料庫，還用到Java 17最新的預覽功能，例如Pattern Matching for Switch。
執行Pitest之後出現圖5所示的錯誤訊息：
▲圖5：Pitest無法辨認byte code格式
很簡單啊，就是執行Pitest的時候加上—enable-preview參數就好了啊。問題是，要加在哪裡？試了幾種方式，後來有團隊成員找到正確的格式，如圖6所示。
▲圖6：加上—enable-preview參數讓Pittest支援Java 17預覽功能
***
打破個人的瓶頸
瓶頸就是系統中生產力最弱的環節，每一個人都有自己擅長的地方，也有自己鬼遮眼的時候。軟體開發是一個動態的系統，採用傳統的單人開發模式（solo programming），每位開發人員同時各自開工，看似生產效率很高，但事實上很可能這些各自執行的thread經常處於block（卡住）狀態。
Pair programming可以稍微改善這種情況，但兩個人一組還是比不上全部的人一組。你可能會說：「全部的人一組還是會有盲點啊，可能這個鬼很厲害，把全部的人的眼睛都遮住了。」沒錯，可能會這樣。但從Boundary（邊界）的角度來看，整個團隊一起開發已經是這個團隊能力範圍內最大的「邊界」，也就是他們已經同時間盡其所能的一起合作解決問題。如果這個「鬼」那麼厲害能夠遮住全部人的眼睛，你派一個人或是兩個人去對付這個鬼，更加無法打敗它。
***
友藏內心獨白：團隊一起處裡有價值的工作。
