Recca Chao 的 gitHub page

推廣網站開發，包含 Laravel 和 Kotlin 後端撰寫、自動化測試、讀書心得等。Taiwan Kotlin User Group 管理員。

View on GitHub

軟體測試反模式

文章來源為 Software Testing Anti-patterns 這篇文章

下面會將文章拆分翻譯，方便更多人閱讀

對這個議題想更深入理解的人，可以去他的部落格 Codepipes Blog 看看，相信會有許多收穫。

引言

已經有許多文章討論過軟體開發中測試的反模式（anti-pattern）。不過，這些文章大多數討論的是較為低階的細節，而且經常針對單一的技術或者程式語言進行討論。

這篇文章內，我想要往後退一步，討論並分類出一些高階的測試反模式，這些模式是和單一技術或者語言無關的。

希望不管你喜歡什麼程式語言，都會在這篇文章裡面認出一些對應的模式。

術語

很不幸的，測試的術語尚未取得全面的共識。問一百位開發者整合測試（integration test），部件測試（component test）和 E2E 測試（end-to-end test）的差異是什麼，很可能會得到一百種不同的答案。在這篇文章內我們使用測試金字塔的定義，如下圖：

測試金字塔

如果你不知道什麼是測試金字塔，我建議你先稍微理解它之後再往下閱讀。一些不錯的文章有：

測試金字塔本身就值得撰文討論，特別是針對每個主題需要多少測試數量這個議題。這篇文章目前只是使用這個金字塔對底下兩種測試的定義。注意這篇文章裡沒有提到 UI 測試（金字塔頂端的測試），因為這樣文章討論的議題太過廣泛，也因為 UI 測試的反模式需要獨立出來討論。

因此我們對兩大主要的測試種類，也就是整合測試和單元測試，定義如下：

單元測試 比較不容易有歧義，他們伴隨程式碼出現並直接存取程式碼進行測試。通常這些測試會伴隨 xUnit 框架或類似的 library。這些測試直接對原始碼操作，並能對該元件全盤掌握。單元測試會針對個別的類別/方法/函式進行測試，如果該函式有使用其他的單元，則使用 mock 或者 stub 進行區隔。

整合測試 也有人稱呼為服務測試（service test），甚至元件測試（component test） 則是針對整個元件進行測試。一個元件可能是多個類別/方法/函式、一個模組、一個子系統甚至整個應用。整合測試輸入資料並檢查輸出資料是否正確。通常整合測試會需要先進行某種部署/bootstrap/設置。外部系統根據商業邏輯，可能完全是 mock 出來的，替換成假的（比方說，使用純記憶體的資料庫來取代真實的資料庫系統），也可能是連接真實的系統。

和單元測試比較起來，整合測試可能會需要比較特殊的工具來處理測試環境，或者模擬交互作用與驗證測試結果。

整合測試的定義比較模糊，許多對測試的命名爭議均從這邊開始。整合測試的「範圍」也很有爭議性，包括是否能存取應用內程式碼（黑箱測試 v.s. 白箱測試），或者能否使用 mock 都有人討論。

基本來說，如果：

⋯⋯那這個測試應該屬於整合測試，不屬於單元測試。

處理完命名問題之後，我們可以開始看反模式的列表了。反模式列表順序大致根據出現頻率由高至低做排列。

軟體測試反模式列表