Golang 的測試有點怪
最近在學習 Go 。然後不禁想感嘆，為什麼有些小夥伴的 Go 測試可讀性可以這麼怪(cha)。說好的測試即文件呢？說好的測試邊界呢？說好的 Given When Then 呢？是我功力不行嗎？
我一直相信，程式設計思想或說方法論都屬於可遷移的知識，不管在哪種語言體內。可是看完一些 Go 的測試栗子，我開始慌了~
理想與現實
不信？看官請看：
go-test-bad.png
由於測試用例太長，沒法截全。沒錯，太長，一屏都裝不下。好奇的你，請戳 ->>> ofollow,noindex"> 戳我
不知道你品起來如何，反正我品起來著實有點苦澀。
這樣的栗子，在 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