Golang 的測試有點怪

最近在學習Go。而後不由想感嘆，爲何有些小夥伴的Go測試可讀性能夠這麼怪(cha)。說好的測試即文檔呢？說好的測試邊界呢？說好的Given When Then呢？是我功力不行嗎？

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

理想與現實

不信？看官請看：

因爲測試用例太長，無法截全。沒錯，太長，一屏都裝不下。好奇的你，請戳 ->>> 戳我

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

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

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

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

這是大神TJ Holowaychuk寫的，果真與衆不同。好奇的你，請戳 ->>> 戳我

落地夢想

知足什麼條件的測試，是值得品味的？我以爲，第一是可讀性，第二仍是可讀性，第三仍是可讀性。

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

寫測試代碼也是如此，要寫出她（計算機）能理解的「文章」，也要寫出咱們能品的「文章」。那麼，落地BDD 模式的測試，無疑是種好的選擇。

看官請看：

中心思想突出，結構清晰。開頭先描述主要功能，而後根據不一樣用例場景分別對待描述。

落地的栗子：

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

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

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

• 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 瞭解一下。

寫在最後

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

原文連接