這是有關(guān)單元測試的幾點想法。有關(guān)如何編寫單元測試，我也有幾點建議：

不要使用隨機(jī)數(shù)據(jù)
    盡管在一個界面中產(chǎn)生隨機(jī)數(shù)據(jù)看起來貌似一個好主意，但是我們要避免這樣做，因為這些數(shù)據(jù)會變得非常難以調(diào)試。如果數(shù)據(jù)是在每次調(diào)用時 隨機(jī)生成的，那么可能產(chǎn)生一次測試時出現(xiàn)了錯誤而另外一次測試卻沒有出現(xiàn)錯誤的情況。如果測試需要隨機(jī)數(shù)據(jù)，可以在一個文件中生成這些數(shù)據(jù)，然后每次運 行時都使用這個文件。采用這種方法，我們獲得了一些 “噪音” 數(shù)據(jù)，但是仍然可以對錯誤進(jìn)行調(diào)試。

分組測試
    我們很容易累積起數(shù)千個測試，需要幾個小時才能執(zhí)行完。這沒什么問題，但是對這些測試進(jìn)行分組使我們可以快速運行某組測試并對主要關(guān)注的問題進(jìn)行檢查，然后晚上運行完整的測試。

編寫穩(wěn)健的 API 和穩(wěn)健的測試
    編寫 API 和測試時要注意它們不能在增加新功能或修改現(xiàn)有功能時很容易會崩潰，這一點非常重要。這里沒有通用的絕招，但是有一條準(zhǔn)則是那些 “振蕩的” 測試（一會兒失敗，一會兒成功，反復(fù)不停的測試）應(yīng)該很快地丟棄。

    結(jié)束語

    單元測試對于工程師來說意義重大。它們是敏捷開發(fā)過程（這個過程非常強(qiáng)調(diào)編碼的作用，因為文檔需要一些證據(jù)證明代碼是按照規(guī)范進(jìn)行工作的）的一個基礎(chǔ)。單元測試提供了這種證據(jù)。這個過程從單元測試開始入手，這定義了代碼應(yīng)該實現(xiàn)但目前尚未實現(xiàn)的功能。因此，所有的測試初都會失敗。然后當(dāng)代碼接近完成時，測試通過了。當(dāng)所有測試全部通過時，代碼也變得非常完善了。

    我從來沒有在不使用單元測試的情況下編寫大型代碼或修改大型或復(fù)雜的代碼塊。我通常都是在修改代碼之前為現(xiàn)有代碼編寫了單元測試，這樣可以確保自 己清楚在修改代碼時破壞了什么（或者沒有破壞什么）。這為我對自己提供給客戶的代碼提供了很大的信心，相信它們正在正確運行 —— 即便是在凌晨 3 點。