Особенности огурца и определения шагов - PullRequest
Новая
       11

Особенности огурца и определения шагов

5 голосов
/ 03 августа 2011

Я новичок в тестировании огурцов.

Я создал два файла функций: 

events.feature
partner.feature

и мои определения шагов находятся в папке step_definitions: 

./step_definitions/
     events.rb
     partner.rb

Кажется, что Cucumber ищет информацию о шагах во всех файлах .rb.

Есть ли какой-либо способ ограничения возможности просмотра определенного файла определения шага?

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

Причина, по которой я хочу это сделать, заключается в следующих причинах. Я тестирую CMS и хочу протестировать каждый из различных типов контента (события и партнеры) в отдельных функциях.

events.feature 

Feature: Add partner
  As an administrator I can add a new partner

  Scenario: Create partner
    Given I am logged in
    When I create a partner
    Then I should see content

partner.feature 

Feature: Add event
  As an administrator I can add a new event

  Scenario: Create event
    Given I am logged in
    When I create an event
    Then I should see content

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

partners.rb 

Then /^I should see content$/ do
  BROWSER.html.should include('SOME PARTNER CONTENT')
end

events.rb 

Then /^I should see content$/ do
  BROWSER.html.should include('SOME EVENT CONTENT')
end

, что означает неоднозначное совпадение «я должен увидеть контент».

Я понимаю, что есть различные способы структурирования этого, то есть я мог бы создать функцию контента и использовать контуры сценария: 

Feature: Add content
  As an administrator I can add a new content

  Scenario Outline: Create content
    Given I am logged in
    When I create an <content type>
    Then I should see <example content>

    Examples: 
    |event   |March Event | 
    |partner |Joe Blogs   |

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

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

Ответы [ 3 ]

9 голосов
/ 03 августа 2011

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

Then /^(?:|I )should see "([^"]*)"$/ do |text|
  page.should have_content(text)
end

А в сценариях просто назовите это так:

Тогда я должен увидеть "СОДЕРЖАНИЕ ПАРТНЕРА"

  • бесплатный бонус - теперь ваш сценарий стал более читабельным
1 голос
/ 03 августа 2011

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

Feature: Add partner
  As an administrator I can add a new partner

  Scenario: Create partner
    Given I am logged in
    When I create a partner
    Then I should see "partner content"

И, аналогично, в функции вашего мероприятия: 

...
Then I should see "event content"

Тогда вы можете сделать следующее в отдельном файле step_definitions/common_steps.rb: 

Then /I should see "(.*)"$/ do |content|
   BROWSER.html.should include(content)
end

На этом шаге нет ничего конкретного о партнере / событии.Вместо этого сценарии содержат специфичные для данных строки для ваших функций.

Если вы работаете с приложением Rails, гем cucumber-rails фактически создаст для вас несколько общих шагов для тестирования веб-приложений.Даже если вы не используете Rails, может быть полезно взглянуть на некоторые из этих шагов .

0 голосов
/ 01 октября 2011

Я искал это, но, кажется, это невозможно "из коробки".

Мое решение состоит в том, чтобы дифференцировать шаги всегда, используя какое-то дополнительное описание, такое как имя класса, например: 

Scenario: Buildings List
    Given I have a Building with code "B1"
    And I have a Building with code "B2"
    When I go to the list of buildings
    Then I should see "B1" building code
    And I should see "B2" building code

Эти описания "строительного кода" - это все, что вам не нужно для повторного использования шагов между различными файлами / доменами.

...