今天先來聊聊測試的規模與邊界。

測試金字塔

說到單元測試，那就一定要提到 Mike Cohn 在書中提到，有名的「測試金字塔」：

圖片轉自 Martin Fowler 的部落格

Mike Cohn 認為，一個健康的系統，所包含的測試可以包羅萬象，但是單元測試應該要佔最大篇幅，而整合度最大的 UI 測試應該要最少。

從速度的角度來看，筆者認為很合理，因為 Unit Test 執行速度快，包含範圍小，所以可以在最短時間，驗證最多功能，要新增或修改也很靈活。UI 本身就是一個很常修改的東西，而且測試成本高，所以如果太多測試建立在 UI 之上，那麼動輒得咎，會花很多成本在修改測試，但卻只是為了一個「與正確性無關，只是美觀上有差」的修改。因小失大。

Unit Test 與 Integration Test

到底「整合測試」的定義是什麼？跟「單元測試」有什麼區別？他等於是測試金字塔裡的 Service Test 嗎？其實這個問題，筆者認為非常難回答，連 Martin Fowler 與其他幾位大師級人物也常有討論。以下摘錄 Martin Fowler 部落格裡的一段話（但作者是 Ham Vocke）：

Unfortunately the concept of the test pyramid falls a little short... Some argue that either the naming or some conceptual aspects of Mike Cohn's test pyramid are not ideal...Your best bet is to remember two things from Cohn's original test pyramid:

1. Write tests with different granularity
2. The more high-level you get the fewer tests you should have

Stick to the pyramid shape... Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end... don't end up with a test ice-cream cone...Don't become too attached to the names of the individual layers in Cohn's test pyramid...

筆者刻意刪除一些文字，希望能夠凸顯較重要的意圖，如讀者依舊對全文有興趣，請見此連結。

Martin Folwer 希望我們要抓緊的是測試金字塔的「形狀」，抓緊「低階測試多一點、高階測試少一點」的原則，而不用太過計較用字遣詞與各層的界線與定義。他認為我們只要努力避免反模式「測試甜筒」的出現，其實就可以將低測試的成本，並提高易修改性。

Kuma 怎麼看

其實筆者一直是很不喜歡做 UI 測試與「跨系統整合測試」的人。我常常聽很多朋友說他們公司「單元測試做得很少，整合測試做很多，而且是真的有存取 DB 的那種」。我是可以理解原因啦，因為這種測試一開始的確是比較好寫，而且透過坊間一些框架的幫忙，甚至可以不用寫 code，就能達到效果，並且具有一定的保護力。

然而，這當中其實有很多是在開發時，靠單元測試就能找到的問題。在單元測試就抓到問題的話，修復成本其實比較便宜。再者，如前所述，單元測試其實是功能的一部份。如果單元測試品質夠好，自然能建立大家對功能本身的信心，那麼，較高階的測試就可以不用做這麼多，就有一些論述認為，在此前提下，一定階層以上的測試，可以只測「Happy Path」就好。

再者，單元測試的一個測試牽扯範圍都不大，所以一旦需求有改，改單元測試也比較靈活。這點，我認為寫測試跟寫程式是一樣的，當需求變更，我們不需要做到「完全不用修改」，只要做到「改動不會太大」，啊跑測試不要太久，這樣就好了。

謎之聲：「名字什麼的不重要，高低階測試的比重抓準就好。」

Reference

1. Martin Fowler 部落格：https://martinfowler.com/articles/practical-test-pyramid.html
2. Mike Cohn 部落格：https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

tags: ithelp2021