顯然，單元測試也并非免費的午餐。在立即測試模型中，單元測試是有開銷的（在時間和金錢上面）。但是如果你查看右邊曲線的方向，你會發現它花費了更多的開銷——效率曲線急劇下降；而且生產率甚至會變成負值；這些生產率損耗可以很容易導致一個項目失敗。
因此，如果你仍然認為在編寫產品代碼的時候，還是沒有時間編寫測試代碼，那么請先考慮下面這些問題：
1. 對于所編寫的代碼，你在調試上面花了多少時間？
2. 對于以前你自認為正確的代碼，而實際上這些代碼卻存在重大的bug，你花了多少時間在重新確認這些代碼上面？
3. 對于一個別人報告的bug，你花了多少時間才找出導致這個bug 的源碼位置？
對于那些沒有使用單元測試的程序員而言，上面這些問題所耗費的時間的遞增速度是很快的，而且隨著項目的深入，遞增速度會變得更快；而另一方面，適當的單元測試卻可以很大程度地減少這些時間，從而能夠為你騰出足夠的時間來編寫所有的單元測試——甚至可能還有剩余的空閑時間。
n 運行測試的時間太長了
合適的測試是不會讓這種情況發生的。實際上，大多數測試的執行都是非�？斓�，因此你在幾秒之內就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間，因此我們不能每次都運行這些測試，有時你就要暫時停止運行這些測試。
在這種情況下，需要把這些耗時的測試和其他測試分開。通�？梢悦刻爝\行這種測試一次，或者幾天一次；而對于運行很快的測試，則可以經常運行。