到目前為止，我們所提到的自動化測試，都是單元測試這個層級，而自動化測試能做的可不只如此，自動化測試金字塔看起來像這樣：

         ＿＿＿＿
       / 系統測試 \
      ——————
     /   整合測試    \
     ———————
   /     元件測試       \
  —————————
 /       單元測試          \
——————————

1. 單元測試

第一個層級是單元測試 (Unit Test)，主要在於測試我們所寫的，一個函式 或 物件的單一 public 函式是否運作正確。

編寫時與函式有類似的特性，小而獨立的單元測試較容易修改與維護 (低相依性)。

2. 元件測試

系統的複雜性逐漸增加之後，通常會用功能切分出多個子系統，相關聯的多個函式或物件集合組成了一個 元件 (Component)，這些元件就相當於是子系統。

系統在運作時，通常不會呼叫那些實作細節最底層的物件，而是這些 元件 的 介面 (Interface) [1]，元件可以看作是一個功能，設計階段時先將各元件的 Interface 定出規格之後，就能夠分配給團隊成員各自開發細節。

3. 整合測試

一個系統中多個元件的功能會互相使用，而整合測試是著重在，確認不同的元件之間，能夠協調地順暢。

4. 系統測試

簡單來說就是測試整個系統 (產品) 的運作，可能會包含性能測試。

TDD 與 各測試層級

TDD 是開發階段的技巧，因此一定有包含到單元測試，如果搭配其他測試工具或套件的話，TDD 當然也能用在其他測試層級，但較高層級的測試，在編寫上肯定與單元測試會有所不同。

目前的範例都還僅限於單元測試，因為不是複雜的系統，自然也還沒必要處理更高層級的測試 (才不會說是因為還沒寫過複雜的系統的哦)。

參考資料

• Robert C. Martin - 無瑕的程式碼 番外篇－專業程式設計師的生存之道 (Clean Coder) - Ch. 8 測試策略

附註

1. 前一篇提到 Interface 時，是描述在程式語言中，任何物件對外的函式 (public function)；而 元件的 Interface 包著一個較大區塊的功能，一個元件在程式中也是物件，但這個物件通常依賴著多個較細節的物件。