2011-08-09 63 views
4

我正在使用一些使用衆所周知的/可怕的數據建模模式(稱爲EAV)的遺留應用程序。這使得選擇數據生成策略難以在DAL的單元測試中使用。爲什麼?因爲除了表之間的正常Fk/Pk約束(我們在可能的情況下使用)之外,還有其他的關係/約束,只有應用程序層意識到並執行。生成複雜數據庫(EAV)的單元測試數據

根據這個article,寫入和維護最簡單的數據測試是那些依賴於外部定義和靜態數據集的測試。然而,似乎試圖創建一個數據集,其中包含已經在我的應用程序層中「手工」建模的關係,這將是一個DRY違規行爲,這是主要的PITA啓動過程。另一方面,使用我的應用程序層生成測試數據感覺更加令人厭惡,因爲它違反了單元測試的主要指令(隔離),因爲應用程序層中的迴歸可能會導致我的DAL層拋出虛假故障。因爲這個原因,我傾向於靜態數據集選項,除非其他人不得不處理EAV模型的單元測試,並且可以選擇其他選項。

非常感謝。

回答

1

如果DAL不負責強制執行數據存儲中的某些應用程序規則,則不需要確保測試數據符合這些更高級別的規則。單元測試只需要驗證DAL是否強制規定它的職責 - 大概是在數據庫約束,數據類型等內部保留的數據。數據只需符合DAL本身構成有效的前提條件測試用例。更高級別的規則將在應用層的單元測試中進行檢查,DAL將在該單元測試中被剔除或嘲笑。在這些假設下,靜態數據集或使用普通代碼生成的靜態數據集可能足以用於DAL測試。

這很可能是應用程序的「遺留」性質,如果不是不可能單獨測試應用程序和DAL層,則很困難。實際上,這兩層共同將是單個(如果複雜的話)「單元」。在這種情況下,作爲權宜之計,使用應用層生成測試數據是可以接受的(或者可能「可以容忍」是正確的詞)。實際上,這樣的一代將會爲集團的「單位」構成更多的測試案例。由於應用層迴歸導致的DAL失敗應作爲候選錯誤在一個,另一個或兩個層中進行調查。花費在試圖將這兩層分成不同單位的任何時間都可能在長期內產生收益。