我自己管理一個相當大的應用程序（50k +代碼行），它管理一些相當關鍵的業務操作。爲了簡單描述這個程序，我想說這是一個花哨的用戶界面，能夠顯示和更改數據庫中的數據，並且它管理着大約1,000個出租單位，以及約3千個租戶和所有財務。在UI中執行業務邏輯的單元測試數據庫應用程序
當我進行更改時，由於它的代碼量太大，我有時會在其他地方打破某些東西。我通常會在功能層面（即運行程序並通過用戶界面工作）測試它，但我無法測試每種情況。這就是爲什麼我想開始進行單元測試。
但是，這不是真正的三層程序，具有數據庫層，業務層和UI層。許多業務邏輯在UI類中執行，許多事情都是在事件上完成的。使事情複雜化，一切都是數據庫驅動的，而且我還沒有看到（迄今爲止）關於如何單元測試數據庫交互的好建議。
如何成爲此應用程序的單元測試入門的好方法。記住。我以前從未做過單元測試或TDD。我應該重寫它以從UI類中刪除業務邏輯（很多工作）嗎？或者，還有更好的方法？
我會開始使用一些工具，通過UI測試應用程序。有許多工具可用於創建測試腳本，以模擬用戶單擊應用程序。
我還建議你在添加新功能塊時開始添加單元測試。一旦開發了應用程序，創建完整的覆蓋範圍非常耗時，但如果您逐步完成這項工作，則可以分配工作量。
我們通過一個單獨的數據庫來測試數據庫交互，該數據庫僅用於單元測試。通過這種方式，我們有一個靜態和可控的數據集，以便可以保證請求和響應。然後，我們創建c＃代碼來模擬各種場景。我們爲此使用nUnit。
+1添加單元測試你添加功能 – 2010-04-09 16:44:52
+1爲你添加功能的單元測試，但我認爲，增加新的功能時，你應該是機會主義重構老未經測試的代碼，併爲重構位增加新的測試，當您去。這也可以爲您隨時添加更多測試並逐步提高測試覆蓋率提供一個「入口點」。 – Pete 2010-04-09 16:48:42
其中一個選擇是 - 每次出現錯誤時，編寫一個測試以幫助您查找錯誤並解決問題。確保錯誤得到解決後，測試會通過。然後，一旦錯誤得到解決，您就有了一個工具，可以幫助您檢測將來可能會影響您剛剛修復的代碼的更改。隨着時間的推移，您的測試覆蓋率將會提高，並且只要您做出潛在的深遠變化，您就可以運行不斷增長的測試套件。
這總是一個好主意，但這不會幫助測試可能意想不到的奇怪交互。 – 2010-04-09 16:44:15
TDD意味着你在建立（並運行）單元測試的同時。對於你想要做的事情 - 在事實之後添加單元測試 - 你可以考慮使用Typemock（一種商業產品）。另外，你可能已經構建了一個不適合單元測試的系統，在這種情況下，可能需要重構一些（或很多）重構。
重構是更好的方法。儘管這個過程令人望而生畏，但您應該將演示文稿和業務邏輯分開。在分離之前，您將無法針對您的業務邏輯編寫好的單元測試。就這麼簡單。
在重構過程中，您可能會發現一些您甚至不知道存在的錯誤，並最終成爲一個更好的程序員！另外，一旦你重構你的代碼，你會注意到測試你的數據庫交互將變得更容易。您將能夠編寫測試來執行如下操作：「添加新租戶」，這將涉及創建模擬租戶對象並將「他」保存到數據庫。對於下一次測試，您將編寫「GetTenant」，然後嘗試將剛剛從數據庫創建的租戶和您的內存中表示進行比較......然後比較您的第一個和第二個租戶以確保所有字段都匹配值。等等
我認爲從用戶界面分離您的業務邏輯總是一個好主意。這有幾個好處，包括更簡單的單元測試和可擴展性。您可能也想參考基於模式的編程。這裏有一個鏈接http://en.wikipedia.org/wiki/Design_pattern_(computer_science)，可以幫助你理解設計模式。
你現在可以做的一件事是在你的UI類中隔離所有的業務邏輯和不同的業務基礎函數，並且比每個UI構造器或page_load內都有單元測試調用來測試每個業務功能。爲了提高可讀性，您可以在業務功能周圍應用#region標籤。
爲了您的長期利益，您應該研究設計模式。選擇適合您項目需求的模式，並使用設計模式重做您的項目。
一個設計模式不適合這個龐大的應用程序，再加上一個不需要的設計模式被認爲是反模式。有些新手在他們還在學習的時候做。設計模式在需要的地方用於此應用程序。 – Malfist 2010-04-09 17:00:08
這取決於您使用的語言。但通常從一個簡單的測試類開始，它使用一些組成數據（但仍然是「真實的」）來測試您的代碼。讓它模擬應用中會發生什麼。如果您在應用程序的特定部分進行更改，請在更改代碼之前編寫一些可行的內容。現在，由於您已經編寫了測試代碼，因此在嘗試測試整個應用程序時將面臨相當大的挑戰。我建議從小開始。但是現在，當你編寫代碼時，首先編寫單元測試然後編寫你的代碼。你也可能考慮重構，但是我會在你一路進行單元測試的時候，重構重構與重寫的成本。
首先，我會推薦閱讀一本關於單元測試的好書，比如The Art Of Unit Testing。根據你的情況，這是一個有點晚對現有的代碼進行測試驅動開發，但是如果你想要寫它周圍的單元測試，那麼這裏就是我會建議：
而對於新代碼，我建議您使用測試驅動開發來嘗試它。
運氣好（你會需要它！）
+1單元測試藝術 - 好書！ – TrueWill 2010-04-09 17:09:19
身份證強烈建議閱讀文章Working Effectively With Legacy Code。它描述了你正在努力完成的一個可行的策略。
+1但更好地購買這本書。 – starblue 2010-04-10 09:59:42
我建議拿起Michael Feathers的書Working Effectively with Legacy Code。這將向您展示許多用於逐步增加代碼庫測試覆蓋率的技術（並沿途改進設計）。
有沒有更好的方式來開始單元測試比嘗試 - 它不需要很長時間，它很有趣和令人上癮。 但是，只有當你在測試代碼上工作。然而，如果你嘗試通過修復一個像你所描述的應用程序一樣的應用程序來學習單元測試，那麼你可能會感到沮喪和灰心 - 而且你很可能會認爲單元測試是浪費時間。
我建議下載一個單元測試框架，如NUnit或XUnit.Net。 大多數這些框架都提供了簡要介紹的聯機文檔，如NUnit Quick Start。閱讀一下，然後選擇一個簡單的自包含類：
嘗試編寫一些測試以獲得該類的良好覆蓋率，然後編譯並運行測試。
一旦你瞭解了這一點，開始尋找機會refactor your existing code，特別是在添加新功能或修復錯誤時。當這些重構導致符合上述標準的類時，請爲它們編寫一些測試。一旦你習慣了它，you can start by writing tests。
我還沒有嘗試爲遺留應用程序添加測試，因爲它確實是一件非常困難的事情。如果您打算將某些業務邏輯從UI中分離出來並放在單獨的層中，那麼您可以在這裏添加您的初始測試單元（重構和TDD）。這樣做會給你一個關於爲你的系統創建單元測試的介紹。這確實是很多工作，但我想這是最好的開始。由於它是一個數據庫驅動的應用程序，因此建議您在創建測試時使用一些模擬工具和DBunit工具來模擬數據庫相關問題。
@Malfist：50K +代碼行不是很大：它最好是中等。我主要是自己編寫一個200KLOC +應用程序（沒有考慮測試行），我認爲它是中等的，不是大的:) – SyntaxT3rr0r 2010-04-09 17:32:11