Golang 的測試有點怪

最近在學習Go。然後不禁想感歎，為什麼有些小夥伴的Go測試可讀性可以這麼怪(cha)。說好的測試即文檔呢？說好的測試邊界呢？說好的Given When Then呢？是我功力不行嗎？

我一直相信，編程思想或說方法論都屬於可遷移的知識，不管在哪種語言體內。可是看完一些 Go 的測試栗子，我開始慌了~

理想與現實

不信？看官請看：

go-test-bad.png

由於測試案例太長，沒法截全。沒錯，太長，一屏都裝不下。好奇的你，請戳 ->>> 戳我

不知道你品起來如何，反正我品起來著實有點苦澀。

這樣的栗子，在awesome-go列表的開源庫，還不少。不行，不行，不能被帶歪了(PS: GitHub 的確是全球最大的基友社區啊，容易帶歪人，hahaha)。

插播一條：多品整潔，簡單的代碼，有利於保護髮際線。

當然不能“一棒子打死船人”，要有發現美的眼睛。看官請看：

go-test-good.png

這是大神TJ Holowaychuk寫的，果然不同凡響。好奇的你，請戳 ->>> 戳我

落地夢想

滿足什麼條件的測試，是值得品味的？我覺得，第一是可讀性，第二還是可讀性，第三還是可讀性。

常聽說 測試即文檔，那麼問題來了，好讀的文檔，長啥樣？讀小學的時候，老師就有教導說，寫作文要，結構清晰，中心思想突出!!!

寫測試代碼也是如此，要寫出她（電腦）能理解的“文章”，也要寫出我們能品的“文章”。那麼，落地BDD 模式的測試，無疑是種好的選擇。

看官請看：

bdd.png

中心思想突出，結構清晰。開頭先描述主要功能，然後根據不同用例情境分別對待描述。

落地的栗子：

bdd-test.png

有木有看起來很舒服！！！你是不是在想，測試實現代碼呢？看官您接著看：

bdd-given-when-then.png

完整栗子，好奇的你，請戳 ->>> 戳我

上面的栗子，落地就是測試三段式，GIVE-WHEN-THEN：

given-when-then.png

• Given: set up context for a behaviour
• When: specify some action
• Then: specify some outcome

Action + Outcome = Behaviour，行為是測試關注的核心。Given，測試案例業務情境的準備，主要包含準備業務資料、Mock 外部依賴、準備使用者資訊。 隨著業務的越複雜，測試內容相關的準備也會越來與複雜，準備業務資料的過程也會越來越耗時間。舉個栗子，對於API測試來說，相對需要花時間寫的就是Given的過程。Then，主要是寫斷言，Assert一下API的返回資料，When，觸發的動作，就是簡單的發一下請求，調用一下API。

在插播一條：如何解決 Given 編寫耗時的問題，DSL Fixture 瞭解一下。

寫在最後

coffee.jpeg

咖啡喝完了，接下來我也不知道怎麼寫了，點到為止吧，因為後面的我也不會啊...

原文連結