TDD和3層架構

我需要在3層架構中實現TDD。TDD和3層架構

書籍和博客中的示例在測試字符串中字符串的出現或測試Stack的Pop函數時很有意義。但是對於N層應用程序，我們有UI，Business Tier和Data Tier數據層依次調用所需的存儲過程並獲取數據。

TDD背後的概念是單獨執行測試，這意味着我們必須模擬或僞造數據。

但我對這種方法的懷疑是什麼應該TDD測試。我的理解是，它測試是否例如GetCustomer函數返回預期的結果。

現在我的問題是如果存儲過程有一個錯誤，TDD不會捕獲該錯誤，因爲數據不是使用Buggy存儲過程提取的。另外如何測試業務&調用存儲過程和存儲過程的數據層功能已實施所有業務規則。

而且還有如何實施用於CRUD操作的TDD？

任何例子將是非常有益的充分理解TDD

問候

來源

2012-01-04 jigsmshah

TDD不是唯一的測試形式。這只是其中之一。你是否告訴某人其他測試（集成測試，性能測試等）不再被使用？你認爲TDD是你做的唯一一種測試？ – 2012-01-04 20:03:31

當你說你需要使用TDD時，你的意思是你想要做，還是有人希望你做到這一點？只是好奇。 – Mathias 2012-01-07 04:17:19

對我而言，這聽起來也許令TDD與單元測試混淆了。 – Mathias 2012-01-07 04:18:47

編寫測試證明，功能和業務需求得到滿足的概念。因此，我使用正在使用的類的公共接口進行編碼。公共接口深入內部和私人類。如果在較低級別拋出異常，或者如果函數返回錯誤的數據，我會根據業務規則在測試中捕獲它。

例如，如果Employee是一個業務類，它調用EmployeeSerializer.GetAll（），我只需要測試Employee.GetAll。如果EmployeeSerializer（）沒有返回正確的數據，我會知道它。如果EmployeeSerializer拋出一個意外的異常，我會知道它。如果EmployeeSerializer沒有拋出正確的異常，我就會知道它。

不要編寫測試代碼來驗證實現細節。對其進行編碼以測試業務規則。這意味着你測試業務對象。爲了促進這項工作，我標記了我的數據訪問對象INTERNAL，因此我無法在他們打算使用的業務環境之外對其進行測試。

但這就是我，我確信其他人有不同的意見。

附錄：儘可能保持業務規則不受存儲過程的影響。另外，使用[Setup]和[TearDown]設置已知的測試。請記住，測試會測試整個業務規則。只要測試單獨執行，並且在測試完成時可以將環境恢復到原始狀態，您就可以自由地儘可能多地完成測試。所以如果你想插入數據，確保你有一個商業類的方法。更新，刪除和選擇相同。

來源

2012-01-04 20:19:23

+1：「儘可能避免存儲過程中的業務規則」 – 2012-01-05 03:15:32

首先我會說讀一點關於Mocks（你嘲笑角色......不是數據/對象）。

W.r.t.以你的例子，我會有

單元測試演示類/ viewmodel（你的UI層）。我在這裏嘲笑業務層/角色。驗證演示類在我做這些服務時調用正確的方法X
針對域類（業務層）的單元測試。這裏我嘲笑數據訪問層。驗證在執行時調用GetCustomer（）X
集成測試測試MyRepository.GetCustomer（）實際上是否從「真實」測試數據庫中正確提取數據。所以理想情況下，您的StoredProc中的錯誤應該在此處被捕獲並標記出來。

除此之外，可能存在的錯誤是合同兩邊的雙方對於其他人的行爲應該有不同的想法。爲此，您可以編寫一些端到端的驗收測試，將所有組件連接在一起（如他們將在生產中一樣）。

TDD可以用於上述所有。

來源

2012-01-05 05:07:30 Gishu

回答

相關問題