2013-10-22 63 views
2

我們有非常大的rails應用程序,目前我們正在從TestUnit/fixture轉換到Rspec/FactoryGirl。我們的數據庫有很多「系統」表,其中數據不變或很少更新。例如FactoryGirl,Rspec和複雜的數據庫結構

user_types 
ID NAME      ... 
1 System Adminisrator  ... 
2 Organization Administrator ... 
.... 
9 Mega Administrator   ... 

另外我們有很多配置表和它們之間的長引用。例如:

master_organizations many-to-many organizations has_many 
plan_years has_many products has_many plans 

organizations has_many employees ... and so on 

而且我們需要在所有規格運行之前配置所有系統表和至少一個組織。然後,如果需要,每個套件都可以將其他數據添加到數據庫。

所以問題是如何構建一個好的,複雜的和靈活的結構,這對於開發人員是可讀的?今天,我們最接近的解決方案是將db結構創建移動到單獨的文件中:爲系統表,配置表等創建shared_contexts。然後在必要時加入。但不確定這種方法是否好。

回答

2

好的,所以你幾乎有恆定的數據,幾乎將永遠存在。在生產中,在您的開發機器上,在每次測試運行中等等。然後您的數據會發生變化;在生產過程中,它是由用戶生成的數據,在需要進行模擬的測試中。

現在我們只需要爲每項工作使用正確的工具。幾乎是恆定的數據是什麼種子是爲,而模擬變化的數據是工廠閃耀。

由Rails提供的種子並不是那麼棒,但由於一些寶石的緣故,它可以變得非常好。

SeedFu爲您提供了一個很好的DSL,用於定義在隨後的運行中不會重複的種子。例如。

User.seed_once(:email, 
    { :email => "[email protected]", :name => "Jon" }, 
    { :email => "[email protected]", :name => "Emily" } 
) 

Seedbank給出了一些很好所需結構種子文件。它覆蓋了默認的rake db:seed任務,併爲各地不需要的種子提供環境特定的文件夾。所以你會有這樣的東西:

db/seeds/ 
    development/ 
    users.seeds.rb 
    organizations.seeds.rb 
    user_types.seeds.rb 

這樣,你不需要有很多重疊的概念(夾具等)。種子處理常數數據,工廠主要處理測試特定的數據。希望它會有用處。

注意:如果您的測試可以是獨立的,並且不依賴種子或其他數據庫狀態,那當然更好。但實際上,您的一些數據與其周圍的模型一樣,也是您的應用程序的一部分。我們的方法可能帶來一些麻煩(總是在遷移,數據庫清理策略上運行種子),但迄今爲止它對我們很有用。調整適合您的用例的部分。