2009-01-13 27 views
7

當有許多人在項目中工作時,所有人都可以改變數據庫模式,單元測試/測試/驗證的最簡單方法是什麼?我們迄今爲止的主要建議是爲每個表編寫測試以驗證列名稱,約束等。你如何(單元)測試數據庫模式?

其他任何人做了類似/更簡單的事情嗎?我們使用C#與SQL Server,如果這有什麼真正的區別。

更新:

  • 我們正在使用SSIS包做大量的工作,以便有很少的C#代碼編寫單元測試agains該項目的部分。
  • 創建表/存儲過程的代碼分佈在SQL文件中。由於構建系統,我們也可以維護一個單獨的VS DB項目文件,但我不確定這將如何幫助我們驗證架構。

回答

4

一個可能的答案是使用Visual Studio for Database開發人員並使用代碼的其餘部分將您的架構保持在源代碼管理中。這可以讓你看到不同之處,你會得到誰改變了什麼的歷史。

或者,您可以使用像SQLCompare這樣的工具來查看與另一個數據庫相比已修改的內容。

0

這是一個有趣的問題!有很多工具用於測試存儲過程,但不用於測試數據庫模式。

您是否發現爲代碼編寫的單元測試通常會發現數據庫模式的任何問題?

我使用的一種方法是編寫存儲過程,將測試數據從開發人員的模式複製到測試模式。這是相當粗糙和準備好的,因爲存儲過程在遇到模式之間的任何差異時通常會崩潰,但它會提醒您任何未被告知的更改。

並提名某人成爲監視架構更改的DBA?

3

就我而言,您的(關係數據庫)做了兩件事:1)保留數據和2)保存數據之間的關係。

保持數據是不是一種行爲,所以你不會測試它

,並確保關係只是使用約束。很多的限制。到處都是。

0

這並不真正適合單元測試的範例。我會建議版本控制模式並限制對單個合格團隊成員(如DBA或團隊負責人)的寫入訪問權限,他們可以驗證針對整個應用程序的任何請求更改。模式更改不應該隨意進行。

0

難道你沒有發現爲代碼編寫的單元測試通常會發現數據庫模式的任何問題嗎?

這當然假設你的測試測試了一切。

0

我不得不做這種類型的事情,雖然不是在C#中。首先,我根據Ode to Code (page 1 of 5)的討論(還有現有的工具可以做類似的事情)構建了一個模式遷移工具。重要的是,我建立的遷移工具允許您指定要應用更改的數據庫以及您想要應用的版本。然後,在測試第一種方法之後,無論何時我需要進行模式更改,我都會編寫一個測試腳本,它將創建測試數據庫,在我的目標更改腳本之前對版本進行版本更改,添加一些數據,應用更改腳本測試,並確認數據處於預期狀態。

我的主要目標是確認在模式遷移過程中沒有數據丟失或損壞,而不是特別檢查模式是否處於特定狀態。需要了解您的生產數據集,以便您可以爲測試編寫有代表性的樣本數據。

這是值得商榷的,如果這應該被視爲單元測試或集成測試。我傾向於認爲它是集成測試,基於這樣一個事實,即我不想在每次迭代我的代碼時運行舊測試。無論你想怎麼稱呼它,我都覺得它是適合這種情況的有用工具。