RSpec: opisać, kontekst, cecha, scenariusz?

describe, context, feature, scenario: Jaka jest różnica (e) spośród czterech i kiedy mogę używać każdego z nich?

contextJest alias describe, a więc są funkcjonalnie równoważne. Możesz ich używać zamiennie, jedyną różnicą jest sposób odczytu pliku specyfikacji. Na przykład nie ma różnicy w wynikach testu. Książka RSpec mówi:

„Zwykle używamy describe()do rzeczy i context()kontekstu”.

Osobiście lubię używać describe, ale widzę, dlaczego ludzie wolą context.

featurei scenariosą częścią Kapibary, a nie RSpec, i są przeznaczone do testów akceptacyjnych. featurejest równoważne describe/ contexti scenariorównoważne it/ example.

Jeśli piszesz testy akceptacyjne z Kapibarą, użyj feature/ scenariosyntax, jeśli nie, użyj describe/ itsyntax.

Dziś rano, pisząc specyfikacje, miałem to samo pytanie. Zwykle głównie używam describei nie myślę o tym specjalnie, ale dzisiejszego ranka miałem do czynienia z wieloma przypadkami i różnymi specyfikacjami dla jednego modułu, więc musiało to być zrozumiałe dla następnego programisty, który przeczyta te specyfikacje. Zapytałem więc Google o to i znalazłem to: opis a kontekst w rspec , którego odpowiedź uważam za całkiem interesującą:

Zgodnie z kodem źródłowym rspec „kontekst” jest po prostu aliasem metody „opisywania”, co oznacza, że ​​nie ma funkcjonalnej różnicy między tymi dwiema metodami. Istnieje jednak różnica kontekstowa, która pomoże uczynić testy bardziej zrozumiałymi, używając obu z nich.

Celem „opisywania” jest zawarcie zestawu testów na jednej funkcjonalności, podczas gdy „kontekst” polega na zawinięciu zestawu testów na jedną funkcjonalność w tym samym stanie.

Opierając się na tej zasadzie, napiszesz taką specyfikację:

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do
  
  # 1st state of the feature/behaviour I'm testing
  context "without a order param" do
    ...
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with a given order column" do
    ..
  end

  # Last state of the feature/behaviour I'm testing
  context "with a given order column + reverse" do
    ..
  end
end

Nie jestem pewien, czy jest to ogólnie przyjęta zasada, ale uważam to podejście za jasne i dość łatwe do zrozumienia.

Rozszerzając doskonałą odpowiedź Pierre'a , zgodnie z dokumentami :

Funkcja i scenariusz DSL odpowiadają odpowiednio opisaniu i temu. Te metody to po prostu aliasy, które umożliwiają odczytywanie specyfikacji funkcji w ramach testów klientów i testów akceptacyjnych.

Tak więc dla osób zaznajomionych z terminami Mocha opisującymi i to (które lepiej nadają się do opisywania zachowania testu z perspektywy użytkownika, stąd Mocha działa przede wszystkim jako front testowy framework), możesz:

• wybierz zawsze i używaj tylko describei / itlub innego parowania
• wybierz opcję użycia itwewnątrz contextbloku, który wymaga wielu potwierdzeń / testów w określonym stanie aplikacji

Korzystając z drugiej opcji, nadal można kierować się intencją „... zawinąć [ping] zestaw testów dla jednej funkcjonalności w tym samym stanie”.

Twoje testy mogą więc wyglądać tak:

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without an order param" do
    # 1st and only test we want to run in this state
    it "asks the user for missing order param" do
     ...
    end
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with an invalid order param" do
    # 1st test we want to run in this state
    it "validates and rejects order param" do
      ...
    end
    # 2nd test we want to run in this state
    it "returns an error to user" do
      ...
    end
  end

  # 3rd state of the feature/behaviour I'm testing with multiple tests
  context "with a valid order param" do
    it "validates and accepts order param" do
      ...
    end
    it "displays correct price for order" do
      ...
    end
    unless being_audited
      it "secretly charges higher price to user" do
        ...
      end
    end
  end
end

W ten sposób featurecałkowicie pomijasz słowo kluczowe, którego możesz chcieć użyć do określonych funkcji interfejsu użytkownika lub jeśli wykonujesz FDD (programowanie oparte na funkcjach), co może być dla niektórych niewygodne. Poproś zespół programistów o wkład tutaj.

Uwaga: nie zawsze stosujemy się do standardów branżowych, wyobraź sobie, że wszystkie nasze testy wzorowaliśmy na filozofii Volkswagena?