Что такое синтаксис для написания определений тестов в Cucumber?

Question

Каков фактический синтаксис для написания определений шагов в Cucumber? Я видел, как это написано по-разному. Нет ли определенного синтаксиса? Я знаю, что якоря не являются обязательными, но есть ли основное правило?

Я новичок в огурце и оценю информацию о детях, чтобы помочь мне понять основы. Спасибо, парни!

Answer 1

Я планировал направить вас к онлайн-документации, но онлайн-документация, которую я знаю (at cucumber.io и at relishapp.com), на самом деле не отвечает на ваш вопрос. (Он содержит много примеров, хотя и заслуживает внимания.)

В реализации Ruby для огурца файлы определения шага - .rb файлов в каталоге features/step_definition. Они содержат ряд вызовов методам, каждый из которых определяет реализацию шага Охотника. Вот пример:

Given /^there is a user named "(.*)"$/ do |username| 
    # code that creates a user with the given username 
end 

Есть несколько методов, которые определяют действия: Given, When, Then, And и But. Все они делают то же самое, и вы можете использовать любой, чтобы определить любой шаг. Лучшая практика - использовать тот, который лучше всего читает с шагом, который вы определяете (никогда And или But).

Аргумент, переданный методу определения шага, является регулярным выражением, предназначенным для соответствия одному или нескольким шагам в файлах Gherkin .feature. Вышеупомянутый пример соответствует следующему этапу:

Given there is a user named "Ade Tester" 

(«Тестер Ade» может быть любым).

Блок, переданный методу определения шага, запускается, когда Cucumber выполняет шаг, который соответствует регулярному выражению. Он может содержать любой код Ruby, который вам нравится.

Соответствующие группы (заключенные в круглые скобки) в регулярном выражении передаются блоку в качестве параметров блока. Количество согласованных групп должно соответствовать количеству параметров блока, или вы получите сообщение об ошибке. Общим соглашением является объединение сопоставимых групп, которые соответствуют строкам в кавычках, чтобы визуально отделять их от фиксированной части шага, как я это делал выше, но это чисто соглашение, и вы можете не делать этого.

Регулярное выражение не обязательно соответствует всем шагам по умолчанию. Если вы хотите, чтобы определение соответствовало только целым шагам, вы должны принудительно применять это в регулярном выражении, как это было в приведенном выше примере с ^ и $. Сделайте это, если у вас нет веских оснований. Это определение шага (без $)

Given /^there is a user named "(.*)"/ do |username| 
    create :user, username: username 
end 

будет соответствовать

Given there is a user named "Ade Tester" on weekdays but "Dave Schweisguth" on weekends 

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

---

В функции/step_definitions/documentation.rb:

When /^I go to the "([^"]+)" documentation$/ do |section| 
    path_part = 
    case section 
     when "Documentation" 
     "documentation" 
     else 
     raise "Unknown documentation section: #{section}" 
    end 
    visit "/documentation/#{path_part}/topics" 
end 

Then /^I should see the "([^"]+) documentation"$/ do |section| 
    expect(page).to have_css('h2.doctag_title a', text: section) 
end 

Эти шаги осуществляют веб-приложение. Они примерно так же просты, как и могут быть, пока они практичны.

Answer 2

A хорошее определение шага должно иметь в своем блоке один вызов метода, например.

When "Frank logs in" do 
    login user: @frank 
end 

Bad определения шага есть много кода в их блоке например

When "I login as Frank" do 
    visit root_path 
    fill_in login_email, with: 
    # lots of other stuff about HOW to login 

    ... 
end 

Другого плохих определения шага использовать очень сложные регулярные выражения с большим количеством аргументов.

Ужасно Определения шагов определяют другие определения шагов и делают вещи bad определения шагов.