2012-02-10 50 views
22

我只是想知道別人是如何組織大型規範文件(特別是型號)有許多背景和部分組織在描述了驗證和其他規格可在一些有意義的方式進行分組塊。Rspec的&大規格文件組織

難道你們把所有關於該型號同規格文件中的模型的規格,或者你分割成模塊的方式或其他?

我從來沒有關心太多關於這個到目前爲止但我想知道別人怎麼做,因爲似乎沒有是某種圍繞最佳實踐或此類協議。

我有一些非常大的規範文件,對一些,我想整理成較小的文件模型,並有很少或幾乎沒有跨不同車型共享,所以我不知道共享的例子是否會成爲這樣的功能去解決這個問題(不管重用性)還是有更好的方法。有什麼建議麼?

在此先感謝。

+0

我通常把一切都在一個單獨的文件和摺疊/展開塊好一點導航代碼。這是一個巨大的文件的痛苦,但我從來沒有與我懶惰分開在類/實例方法,回調/驗證等測試... – apneadiving 2012-02-10 13:16:38

+0

我想你可以使用include和mixin每個文件到基地這種方式。按照約定在目錄結構中按類/子類組織文件。我認爲這是我會做的,再加上大衛的回答如下。感謝殺手問題! – ipd 2012-09-28 17:00:55

回答

22

嵌套上下文可以幫助你在這裏,但保持淺(一般爲1級深)。在每個示例中都有兩個變量需要考慮:givens(起始狀態)和正在調用的方法。您可以通過法或國家集團的事情:

# by method 
describe Stack do 
    describe "#push" do 
    it "adds an element to an empty stack" 
    it "adds an element to a non-empty stack" 
    end 

    describe "#pop" do 
    it "returns nil from an empty stack" 
    it "returns the last element of a non-empty stack" 
    it "removes the last element from a non-empty stack" 
    end 
end 

# by state 
describe Stack do 
    context "when empty" do 
    specify "push adds an element" 
    specify "pop returns nil" 
    end 

    context "when not empty" do 
    specify "push adds an element" 
    specify "pop returns last element" 
    specify "pop removes last element" 
    end 
end 

我用這兩種方法,看到他們兩個的工作真的很好,真的很厲害。任何一種方法的關鍵在於,這些例子在你從上到下閱讀時會講述一個故事。隨着需求的發展,這意味着您需要查看此文件,就像您執行代碼一樣。 一個簡單的方法來檢查規範有意義是與文檔格式運行:

rspec stack_spec.rb --format documentation 

該吐出所有的名字,以便(只要你不使用--order蘭特):

Stack 
    #push 
    adds an element to an empty stack 
    adds an element to a non-empty stack 
    #pop 
    returns nil from an empty stack 
    returns the last element of a non-empty stack 
    removes the last element from a non-empty stack 

Stack 
    when empty 
    push adds an element 
    pop returns nil 
    when not empty 
    push adds an element 
    pop returns last element 
    pop removes last element 

一旦你看到這個輸出,您正在使用,使組織是否感覺到與否這將是很清楚的給你。