我已經忍了使用VisualStudio的綜合測試環境的一些測試， 他們simultate什麼我的web應用程序會做通過調用BLL方法 （他們唯一的UI層應該知道和互動）...如果我的應用程序只能調用BLL metods，爲什麼要爲我的SQL，DAL和BLL做UnitTest？
所以如果他們的行爲是正確的 - 我會通過我的測試 - 爲什麼 我會爲許多 文獻指示我要做的低層編寫測試，例如DAL /存儲過程？
謝謝大家，彼得。
端到端測試很好，並確保您的應用程序適用於某些場景。
Misko Hevery在test categorization上發表了一篇很好的博客文章，他分裂了單元測試，集成測試和端到端測試。
單元測試 單元測試檢查該函數方法中的邏輯是否正確執行了錯誤處理，並且錯誤處理是否正確完成。理想情況下，這些測試應該在幾毫秒內運行，而不是幾秒鐘。如果一個函數需要與某些東西交互，比如DAL，那麼你應該嘲笑DAL的這個接口，因爲真正的交互需要很長時間才能運行。這些提供投資
最好的回報集成測試 這種測試水平檢查業務邏輯層之間的交互也正是他們應該做的事情。這是您的單元測試將與接口交互的地方，如DAL，並檢查「接線」是否正確。應該有其中的幾個，但沒有太多，因爲這將影響您的構建時間
端至端測試 這些都是很好的，因爲他們檢查一切從UI掛在一起，一路下跌至DAL。這些測試需要更多的「接線」，並檢查你的用戶可以做什麼不會殺死你的應用程序。這些還可以包括您的FitNesse和網絡測試，如Selenium，正在通過。
單元測試提供了最好的投資回報，並且會比其他地區獲得更多昂貴的錯誤，但它有很好的組合。
從NUnit的背景
測試SPS /數據訪問說起是不容易的事情。每次測試運行時，您都必須確保您擁有一個「乾淨」的數據庫，並在一開始就有預期的數據，以保證您獲得預期的結果。因此，您需要每次都從乾淨的備份中恢復數據庫，或者確保您的測試在測試開始之前用所需的數據設置數據庫。
單元測試理想情況下應該儘可能快地運行，並且是DAL經常在單元測試時被嘲笑的原因之一 - 去除昂貴的數據庫交互過程。你必須小心的是，如果你爲SP/DAL編寫「單元測試」，那麼對測試執行時間的影響可能會激增，根據我的經驗，可能會導致人們無法運行測試，因爲它們需要很長時間。特別是在持續集成環境/構建環境中，測試運行時間越長，準備構建任務的時間就越長。
我個人認爲我喜歡在我的單元測試中使用模擬和實際數據庫訪問的組合，因爲我想知道我的代碼將按照預期一直運行到數據庫和從數據庫中捕獲愚蠢的錯誤，如SP缺少/錯誤（單元/集成/功能測試之間的邊界）。但是，如果它不那麼重要，我會使用模擬。
請參閱下面的AutomatedTester所做的區別，但它聽起來不像是在編寫單元測試，其中每個「單元」已被隔離，而是集成測試？ – 2009-07-17 09:05:01