RSpec: опис, контекст, особливість, сценарій?

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

contextЄ псевдонімом describe, тому вони функціонально еквівалентні. Ви можете використовувати їх взаємозамінно, різниця лише в тому, як читається файл специфікації. Наприклад, немає різниці в тестовому виході. У книзі RSpec написано:

"Ми схильні використовувати describe()для речей та context()для контексту".

Особисто мені подобається користуватися describe, але я бачу, чому люди віддають перевагу context.

featureі scenarioє частиною Capybara, а не RSpec, і їх слід використовувати для тестів на прийняття. featureеквівалентноdescribe / contextта scenarioеквівалентно it/ example.

Якщо ви пишете приймальні випробування з капібари, використовуйте 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 описує його та його (які краще підходять для опису поведінки тесту з точки зору користувача, отже, 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 (розробка, орієнтована на функції), для когось це може бути незручно. Попросіть тут свою команду розробників.

Caveat: не завжди дотримуйтесь галузевих стандартів, уявіть, якби ми моделювали всі наші тести за філософією Volkswagen?