到目前為止,我們所提到的自動化測試,都是單元測試這個層級,而自動化測試能做的可不只如此,自動化測試金字塔看起來像這樣:
____
/ 系統測試 \
——————
/ 整合測試 \
———————
/ 元件測試 \
—————————
/ 單元測試 \
——————————
第一個層級是單元測試 (Unit Test),主要在於測試我們所寫的,一個函式
或 物件
的單一 public 函式是否運作正確。
編寫時與函式有類似的特性,小而獨立的單元測試較容易修改與維護 (低相依性)。
系統的複雜性逐漸增加之後,通常會用功能切分出多個子系統,相關聯的多個函式
或物件
集合組成了一個 元件
(Component),這些元件就相當於是子系統。
系統在運作時,通常不會呼叫那些實作細節最底層的物件,而是這些 元件
的 介面
(Interface) [1],元件可以看作是一個功能,設計階段時先將各元件的 Interface 定出規格之後,就能夠分配給團隊成員各自開發細節。
一個系統中多個元件的功能會互相使用,而整合測試是著重在,確認不同的元件之間,能夠協調地順暢。
簡單來說就是測試整個系統 (產品) 的運作,可能會包含性能測試。
TDD 是開發階段的技巧,因此一定有包含到單元測試,如果搭配其他測試工具或套件的話,TDD 當然也能用在其他測試層級,但較高層級的測試,在編寫上肯定與單元測試會有所不同。
目前的範例都還僅限於單元測試,因為不是複雜的系統,自然也還沒必要處理更高層級的測試 (才不會說是因為還沒寫過複雜的系統的哦)。