RSpec: описание, контекст, функция, сценарий?

describe, context, feature, scenario: В чем разница (s) между четырьмя и когда я могу использовать каждый из них?

Это contextпсевдоним для describe, поэтому они функционально эквивалентны. Вы можете использовать их как взаимозаменяемые, разница только в том, как читается ваш файл спецификации. Например, нет разницы в результатах теста. В книге RSpec говорится:

«Мы склонны использовать describe()для вещей и context()для контекста».

Лично мне нравится использовать describe, но я понимаю, почему люди предпочитают context.

featureи scenarioявляются частью Capybara, а не RSpec, и предназначены для использования для приемочных испытаний. featureэквивалентен describe/ contextи scenarioэквивалентен it/ example.

Если вы пишете приемочные тесты с помощью Capybara, используйте синтаксис feature/ scenario, если не используйте синтаксис describe/ it.

Этим утром, когда я писал некоторые спецификации, у меня возник тот же вопрос. Обычно я в основном использую describeи не особо задумываюсь об этом, но сегодня утром я имел дело с множеством случаев и разными спецификациями для одного модуля, поэтому это должно было быть легко понятным для следующего разработчика, который прочитает эти спецификации. Я спросил об этом у Google и нашел вот что: описание и контекст в rspec , ответ на который я нахожу весьма интересным:

Согласно исходному коду rspec, «контекст» - это просто псевдоним метода «описать», что означает, что между этими двумя методами нет функциональной разницы. Однако есть контекстная разница, которая поможет сделать ваши тесты более понятными, если использовать их оба.

Цель «описания» - обернуть набор тестов для одной функции, в то время как «контекст» - обернуть набор тестов для одной функции в одном и том же состоянии.

Итак, полагаясь на этот принцип, вы бы написали такую ​​спецификацию:

#
# 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

Не уверен, что это общепринятое правило, но я нахожу такой подход ясным и довольно легким для понимания.

Расширяя отличный ответ Пьера , согласно документам :

Функция и сценарий DSL соответствуют описанию и ему, соответственно. Эти методы представляют собой просто псевдонимы, позволяющие рассматривать спецификации функций как тесты заказчика и приемочные испытания.

Итак, для тех, кто знаком с терминами Mocha description и it (которые лучше подходят для описания поведения теста с точки зрения пользователя, следовательно, Mocha в основном функционирует как среда внешнего тестирования), вы можете:

• выбрать всегда и только использовать describeи itили другую пару
• выбрать использование itвнутри contextблока, который требует выполнения нескольких утверждений / тестов в определенном состоянии приложения

Выбирая второй вариант, вы по-прежнему можете следовать намерению «... обернуть [ping] набор тестов против одной функции в одном и том же состоянии».

Таким образом, ваши тесты могут выглядеть так:

#
# 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

Таким образом, вы полностью пропускаете featureключевое слово, которое вы можете использовать для определенных функций внешнего интерфейса или если вы выполняете FDD (разработка, управляемая функциями), что для некоторых может показаться неудобным. Попросите вашу команду разработчиков поделиться здесь.

Предостережение: не всегда соблюдайте отраслевые стандарты, представьте, если бы мы смоделировали все наши тесты по философии Volkswagen?