Organizacja Rspec i dużych plików spec

Question

Zastanawiam się, jak inni organizują duże pliki spec (szczególnie dla modeli) z wieloma kontekstami i sekcjami zorganizowanymi w bloki opisujące walidacje i inne specyfikacje, które mogą być grupowane w jakiś znaczący sposób.

Czy zachowujesz wszystkie specyfikacje dotyczące modelu w tym samym pliku specyfikacji dla tego modelu, czy też dzielisz się na moduły w taki czy inny sposób?

Do tej pory nie przejmowałem się zbytnio tym, ale zastanawiam się, co robią inni, ponieważ nie wydaje się, że istnieje jakieś porozumienie wokół najlepszej praktyki lub takiej.

Mam kilka naprawdę dużych plików spec dla niektórych modeli, które chciałabym zorganizować w mniejsze pliki, a ich funkcjonalność jest bardzo mała w różnych modelach, więc nie jestem pewien, czy udostępnione przykłady byłyby sposobem do tego celu (bez względu na możliwość ponownego użycia) lub czy istnieje lepszy sposób. Jakieś sugestie?

Z góry dziękuję.

Answer 1

Zagnieżdżone konteksty mogą ci w tym pomóc, ale zachowaj je płytko (zwykle na jednym poziomie głębokości). W każdym przykładzie należy wziąć pod uwagę dwie zmienne: givens (stan początkowy) i jaka metoda jest wywoływana. Możesz grupować rzeczy według metody lub stanu:

# 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 

Użyłem obu podejść i zobaczyłem, że oba działają naprawdę dobrze i naprawdę źle. Kluczem do obu podejść jest to, że przykłady opowiadają historię, czytając od góry do dołu. Ponieważ wymagania ewoluują, oznacza to, że musisz przejrzeć ten plik, tak jak robisz kod implementacji. Łatwym sposobem sprawdzenia, że ​​spec sens jest uruchamianie go z formatyzatora dokumentacja:

rspec stack_spec.rb --format documentation 

To wypluwa wszystkie nazwiska w kolejności (o ile nie używasz --order rand):

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 

lub

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 

Gdy widzisz to wyjście, to będzie całkiem dla ciebie jasne czy organizacja używasz ma sens czy nie.