再談單元測試

　　關于你提出的幾點：1. 單元測試是一種測試，它不是代碼的一部分；2. 單元測試是最低層級的測試，它只保證函數的可靠性，不保證其它；3. 單元測試應該能保證每一個函數的可靠性。

　　當今前端測試的問題在于僅僅對函數的輸出進行驗證并不能很好的確認其行為。因為js還需要對DOM進行操作，需要對CSS進行操作，IE,FF顯示效果不一致等等。使得前端開發程序員不得不人肉進行測試，查看程序是否符合預期的顯示效果。你們認為如何才能提高前端單元測試的有效性呢？

　　說實話這個問題是我剛剛接觸單元測試的時候，也一直被困擾的一個問題，那就是，GUI界面如何單元測試？我記得在幾年前，我還就這個問題特地咨詢過gigix，當時他告訴我說“測試能測試的”。但是當時我對單元測試一知半解的時候，對于這個答案也是不甚了了。

　　今天我不敢說對這個問題已經理解得非常透徹了，但是我想把我的想法說出來，大家討論一下。

　　在解釋這個問題之前，我想重復一下我對單元測試的理解：單元測試是最底層的測試，它只保證函數的可靠性。

　　但是這里有一個重要的概念，我們需要進一步的說兩句：什么叫“函數”？

　　從語法而言，函數就是語言概念上的一個語句塊，這個語句塊接收0個至多個輸入，產生0個至多個輸出。但是，所有的語言都沒有規定函數需要有怎樣的“語義”。于是，我們也不能在解釋器或編譯器層面阻止一個“壞函數”的誕生。例如，下面這兩個函數，如何測試？

x = 1;

function a()
{
   global x = x+1;
   if (x < 10)
       setTimer(100, b);
}
function b()
{
    feed = time.now();
    diff = random(feed).getInteger(10);
    global x = x - diff;
}

　　函數a嚴重依賴于函數b，以及平臺相關的定時器和一個狀態未知的全局變量x。而函數b也依賴于平臺相關的函數time和一個狀態未知的全局變量x。這樣兩個函數要進行測試，難度是非常高的。簡單的說，a幾乎可以認為是無法測試的，因為它并不是一個我們所謂的“輸入-處理-輸出”函數，而是依賴于定時器這樣的平臺相關操作，定時器這種東西是很難模擬的，就算模擬出來意義也不大，因為真實的定時器幾乎可以肯定不會跟模擬的定時器有相同的表現——而這個表現，正是我們編寫這個函數的目的。函數b倒是可以測試，但你必須事先為它模擬好一個時間函數（類），一個隨機數函數（類），和一個確定狀態的全局變量x——這些工作在一些語言里可以做到但要付出很大的代價，在另一些語言里幾乎可以說是不可能的任務。

　　那么，接下來的工作倒也變得很簡單了：我們就要做一個價值上的衡量，我花很多時間精力去實現這些測試基礎框架（對了，這些基礎框架也需要測試），跟我整個系統的測試工作本身相比到底值不值？

　　其實在大部分時候，這個答案是“不值”。如果為了一個系統的單元測試要做如此多的工作，其難度不亞于開發一個新系統，那我們當然會選擇不測試。

　　上面的例子說明了兩點：1、函數并不是天然可測試的；2、不是所有的“函數”都是需要測試的。

原文轉自：http://www.kjueaiud.com