testowanie wieloetapowego przepływu pracy w rspec

Question

Chciałbym wiedzieć o idiomach lub sprawdzonych procedurach testowania wieloetapowego przepływu pracy za pomocą rspec.

Weźmy jako przykład system „koszyk”, gdzie proces zakupu może być

1. gdy użytkownik wysyła do kosza i nie używamy https, przekierowanie do https
2. gdy użytkownik przedkłada koszyk i używamy https i nie ma pliku cookie, tworzymy i wyświetlamy nowy koszyk i odsyłasz ciasteczko
3. , gdy użytkownik przesyła do koszyka i używamy https i jest ważny plik cookie, a nowy element dotyczy innego produkt niż pierwszy element, dodaj linię do kosza i wyświetl obie linie:
4. , gdy użytkownik przesyła do koszyka i używamy https, a plik cookie jest poprawny, a nowa pozycja dotyczy tego samego produktu co poprzednia, należy zwiększyć ilość linii koszyka i wyświetlić obie linie:
5. , gdy użytkownik kliknie przycisk "Kasa" na stronie koszem i jest przy użyciu protokołu hTTPS i jest ciasteczka i kosz jest niepusty i ...
6. ...

Czytałem http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/ który doradza m.in., że każdy „blokować” powinien zawierać tylko jedno twierdzenie: zamiast wykonywać obliczenia, a następnie testować kilka atrybutów w tym samym bloku, użyj "przed" wewnątrz kontekstu, aby utworzyć (lub pobrać) testowany obiekt i przypisać go do @some_instance_variable, następnie napisz każdy test atrybutów jako osobny blok. To trochę pomaga, ale w przypadku opisanym powyżej, gdzie etap testowania n wymaga wykonania całej konfiguracji dla kroków [1..n-1], znajduję się albo powielony kod instalacyjny (oczywiście nie jest dobry) albo tworzony jest wiele funkcji pomocniczych z coraz bardziej nieporęcznymi nazwami (def create_basket_with_three_lines_and_two_products) i wywoływanie ich kolejno w każdym kroku przed blokiem.

Jakieś wskazówki, jak to zrobić mniej gadatliwie/żenująco? Doceniam ogólną zasadę, według której każdy przykład nie powinien zależeć od stanu pozostawionego przez poprzednie przykłady, ale kiedy testujesz wieloetapowy proces i wszystko może pójść źle na każdym kroku, konfigurowanie kontekstu dla każdego kroku to nieuchronnie wymagać będzie ponownego uruchomienia całego zestawu dla poprzednich n kroków, więc ...

Answer 1

Oto jedno możliwe podejście - zdefiniuj obiekt, który tworzy wymagany stan dla każdego kroku i przekazuj go dalej dla każdego kolejnego. Zasadniczo trzeba kpić/skrótową metoda wymaga wszystkich warunków instalacji:

class MultiStep 
    def initialize(context) 
    @context = context 
    end 

    def init_vars 
    @cut = @context.instance_variable_get(:@cut) 
    end 

    def setup(step) 
    init_vars 
    method(step).call 
    end 

    def step1 
    @cut.stub(:foo).and_return("bar") 
    end 

    def step2 
    step1 
    @cut.stub(:foo_bar).and_return("baz_baz") 
    end 
end 

class Cut # Class Under Test 
    def foo 
    "foo" 
    end 
    def foo_bar 
    "foo_bar" 
    end 
end 

describe "multiple steps" do 
    before(:each) do 
    @multi_stepper = MultiStep.new(self) 
    @cut = Cut.new 
    end 

    it "should setup step1" do 
    @multi_stepper.setup(:step1) 
    @cut.foo.should == "bar" 
    @cut.foo_bar.should == "foo_bar" 
    end 

    it "should setup step2" do 
    @multi_stepper.setup(:step2) 
    @cut.foo.should == "bar" 
    @cut.foo_bar.should == "baz_baz" 
    end 

end 

Answer 2

pewnością zbyt późno dla PO, ale może to być przydatne dla innych - gem rspec-kroki wydaje się być zbudowany na taką sytuację : https://github.com/LRDesign/rspec-steps

Warto również spojrzeć na https://github.com/railsware/rspec-example_steps i https://github.com/jimweirich/rspec-given. Postanowiłem przejść przez kroki rspec, ale byłem w pośpiechu i te inne opcje mogą być lepsze dla wszystkich, które znam.