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

Ответ 1

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

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

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

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

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

Ответ 2

Сегодня утром, написав некоторые спецификации, у меня был тот же вопрос. Обычно я в основном использую describe и не особенно задумываюсь об этом, но сегодня утром я имел дело со множеством случаев и разными спецификациями для одного модуля, поэтому для следующего разработчика это должно было быть легко понятным, чтобы прочитать эти спецификации, Поэтому я спросил об этом Google, и я нашел следующее: описать vs. context в 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

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

Ответ 3

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

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

Таким образом, для тех, кто знаком с терминами Mocha, описывают и это (которые лучше подходят для описания поведения теста с точки зрения пользователя, следовательно, 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?