最近在學習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
瞭解一下。
寫在最後
咖啡喝完了,接下來我也不知道怎麼寫了,點到為止吧,因為後面的我也不會啊...
原文連結