人們如何測試他們的業務應用程序？我看過很多「簡單測試」例子的單元測試例子。防爆。一個計算器。人們如何測試數據量大的應用程序？你如何整理你的樣本數據？在許多情況下，一項測試的數據可能根本無法用於另一項測試，這使得只有一個測試數據庫變得困難。你如何測試業務應用程序？
測試代碼的數據訪問部分非常簡單。它正在測試所有對付似乎難以測試的數據的方法。例如，想象一個發佈過程，其中存在大量數據訪問以確定發佈內容，數字是否經過調整等。有多個臨時步驟發生（並且需要測試）以及之後的測試，以確保發佈是成功的。其中一些步驟可能實際上是存儲過程。
在過去，我試過在測試數據庫中插入測試數據，然後運行測試，但老實說寫這種代碼非常痛苦（並且容易出錯）。我也試過只是先建立一個測試數據庫並回滾這些更改。這很好，但在很多地方你也不能輕易做到這一點（許多人會說這是集成測試;所以，我仍然需要能夠以某種方式測試）。
如果答案是沒有一個很好的方式來處理這個問題，它目前只是一些糟糕的事情，這也是有用的知道。
任何想法，想法，建議或技巧值得讚賞。
當我嘗試用回滾解決方案來處理這些集成測試時，我必須通過@Phil Bennett來發表評論。
我對集成測試數據訪問層一個非常詳細的崗位here
我不僅顯示樣本數據訪問類，基礎類和示例數據庫的事務夾具類，而是一個完整的CRUD集成測試瓦特/示例數據顯示。使用這種方法，您不需要多個測試數據庫，因爲您可以控制每個測試的數據，並且在測試完成後，所有事務都會回滾，因此您的數據庫是乾淨的。因爲如果你嘲笑你的業務對象擁有的所有依賴關係，那麼測試你的應用程序邏輯變得非常簡單，因爲你可以在你的應用程序中測試一個實體，一次;）
編輯：那麼你是否正在尋找一個巨大的集成測試，將驗證從邏輯預數據庫/存儲過程運行瓦特/邏輯的一切，最後在回來的路上驗證一切？如果是這樣，你可以打破這個伸到2步：
1 - 單元測試數據推 到您的數據訪問代碼，在此之前發生的邏輯。對於 例如，如果你有一些代碼， 計算基於 一些特性的一些數字 - 編寫一個測試 只檢查，看是否邏輯 這個1層的功能是什麼，你問 做的事。在數據訪問類中剔除任何依賴關係 ，因此您可以僅在 應用程序邏輯的此測試中忽略它。
2 - 集成測試，一旦你把你的 操縱數據（從測試的是上 方法，我們單位），並調用相應的 存儲過程發生的邏輯。做 這裏面的數據具體測試 類，所以你可以回滾之後它的 完成。您的存儲 程序運行後，做一個查詢 針對數據庫現在讓你 對象，我們也做了一些 邏輯對數據和驗證 有你所期望的值 （存儲後的程序邏輯的/ etc）
如果您需要在數據庫中存儲過程運行的項目，只需您在有裏面的邏輯存儲過程的前插入的數據。例如，如果您有需要測試的產品，則可能需要供應商和類別條目在插入產品之前插入，以便爲供應商和類別執行快速而髒的插入操作，以便您的產品插入按計劃工作。
對於許多不同的運行在相同的邏輯，但用不同的數據，只要你喜歡的輸入和持續輸出等
這取決於你在做什麼，你可以使用CSV，多列測試。如果您正在測試業務邏輯組件 - 那麼它在數據來自哪裏並不重要，您可能會使用模擬或手動滾存類來模擬組件在野外會調用的數據訪問例程。我唯一一次混淆數據訪問的時候是我實際測試數據訪問組件本身。
即使是這樣我傾向於在TestFixtureSetUp方法打開一個數據庫交易（顯然這取決於你可能會使用什麼樣的單元測試框架），並在測試套件TestFixtureTeardown結束回滾事務。
聽起來好像您可能正在測試基於消息的系統或具有高度參數化接口的系統，其中有大量輸入數據的排列。
一般而言，所有標準unti測試的規則仍然成立：
一旦做到這一點，你會已經刪除了很多複雜的自測試，希望是良好的結果集的單元測試，並簡化樣本數據。
然後編譯樣本數據以進行仍需要複雜輸入數據的測試樣本數據的一個好方法是Orthogonal testing或請參閱here。
我已經使用這種方法爲WCF和BizTalk解決方案生成測試計劃，其中輸入消息的排列可以創建多個可能的執行路徑。
模擬框架使您能夠測試您的業務對象。 數據驅動的測試通常最終變得比單元測試更多的是一體化測試，他們還帶着管理數據存儲狀態的負擔，測試執行前後的數據存儲狀態以及連接和執行查詢所花費的時間。
在一般情況下，我會避免做單元測試，從您的業務對象觸摸數據庫。至於測試你的數據庫，你需要一個不同的策略。
這就是說，你永遠不能完全擺脫數據驅動的測試，只能限制實際需要調用你的後端系統的測試數量。
我的自動化功能測試通常遵循兩個patters之一：
數據庫連接測試
當我自動化連接到數據庫的測試，我通常會創建一個測試數據庫模板有足夠的數據用於所有測試。運行自動化測試時，將爲每個測試生成一個新的測試數據庫。測試數據庫必須不斷重新生成，因爲測試通常會更改數據。在添加測試時，我通常會將更多數據附加到測試數據庫模板。
這種測試方法有一些很好的優點。顯而易見的好處是測試還可以鍛鍊你的模式。另一個優點是，在設置初始測試後，大多數新測試將能夠重新使用現有的測試數據。這使得添加更多測試變得很容易。
缺點是測試數據庫將變得笨拙。因爲數據通常會隨時添加一個測試，所以它會不一致，甚至可能不現實。當存在重要的數據庫模式更改時（這對我來說通常意味着我最終會詛咒自己），您最終還會詛咒安裝測試數據庫的人員。
如果您無法隨意生成新的測試數據庫，則此類測試顯然不起作用。
模擬持久層測試
對於這個模式，創建mock objects與測試用例生活。這些模擬對象攔截對數據庫的調用，以便以編程方式提供適當的結果。基本上，當你測試的代碼調用findCustomerByName()方法時，你的模擬對象被調用而不是持久層。
有關使用模擬對象測試的好處是，您可以獲得非常具體的。通常，執行路徑在無模擬對象的自動化測試中無法實現。他們還可以讓您免於維護大量的整體測試數據。
另一個好處是缺乏外部依賴性。由於模擬對象模擬持久層，因此測試不再依賴於數據庫。這通常是決定選擇哪種模式時的決定性因素。模擬對象似乎在處理遺留數據庫系統或具有嚴格許可條款的數據庫時更具吸引力。
模擬對象的缺點是它們經常會導致大量額外的測試代碼。這並不可怕，因爲幾乎任何數量的測試代碼在運行測試的次數上分攤時都很便宜，但是如果有更多的測試代碼，然後生產代碼，可能會很煩人。
是的回滾策略在過去對我來說效果很好。 – tjjjohnson 2009-05-27 02:42:53