TDD是什麼箱？

June 03 12:30~12:53

 

前兩天寫了〈白箱測試與黑箱測試（上）〉與〈白箱測試與黑箱測試（下）〉，後來和朋友在Facebook上討論有關TDD（測試驅動開發）與白箱測試，Teddy突然想到一個問題：

TDD所寫的「單元測試」，是一種白箱測試案例還是黑箱測試案例？

TDD因為是先用測試案例來定義規格或是程式行為，借此達到設計production code的目的。所以，TDD這種「開發或設計方法」所產生的測試案例算是一種「黑箱測試」。因為production code根本還沒產生，不可能用TDD寫出白箱測試案例，因此TDD自然也無所謂的「白箱測試涵蓋率」的議題。

***

從Alexander的模式理論來看，設計有兩個面向：決定context或是決定form（套用在本篇的情境，就是先寫測試還是先寫production code）。傳統的設計方式，先寫production code再寫test code，是先設計form，再以測試案例確定這個form與context的合適程度。BDD/TDD則是反過來，先決定context，然後再決定form。依據Alexander對於設計的看法，如果設計者可以「定義出非常詳盡的context，form就自然產生，也就沒有所謂設計的問題。但是實務上要定義非常詳盡的context是很難的（定義出非常詳盡的需求或規格），而不管context就直接把form設計出來，也很難（因為可能做出不是使用者要的東西）。所以，設計經常是遊走於兩端之間。

舉個例外處理的例子，假設用TDD開發一個讀檔案的function，從「需求面」來看，一開始使用者只在意要能成功讀取檔案。但是用Java實作這個function的時候，會遇到IOException。如何處理IOException是開發人員需要關注的議題，使用者一開始也許根本不在意或是也不知道什麼是IOException。

如果「讀檔案會遇到IOException」或是「讀檔案可能會遭遇異常狀況」這件事可以直接被定在「需求（規格）」中，用TDD寫出另一個test case來規範處理異常的行為，那也就不用去管production code一開始是如何處理IOException。但問題在於「實作方式」經常會影響需求，或是讓需求更明確，這時候production code就會反過來幫助我們寫出另一個TDD的測試案例。

看了production code之後幫助開發人員寫出新的TDD測試案例，這是一種「白箱影響（幫助）黑箱」的例子。反過來「黑箱影響（幫助）白箱」也是很常見的狀況。

黑箱、白箱，能幫助開發、測試的，就是好箱XD。

***

友藏內心獨白：自己在電腦上所打的字也要盡量「重複使用」啊。