l

2014年6月5日 星期四

TDD是什麼箱?

June 03 12:30~12:53

image

 

前兩天寫了〈白箱測試與黑箱測試(上)〉與〈白箱測試與黑箱測試(下)〉,後來和朋友在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。

***

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

沒有留言:

張貼留言