Explain the cucumber use of _ruby topics in Ruby on Rails

Mark your unfinished scene with the @wip (work in progress) tab. These scenarios are not taken into account and are not marked as test failures. When an unfinished scenario is completed and the functional test passes, the @wip tag should be removed in order to add this scenario to the test suite.
Configure your default profile to exclude scenes marked as @javascript. They are tested using browsers, and it is recommended that they be deactivated to increase the execution speed of general scenarios.

Configure a different configuration file for the scene that is marked @javascript.

Configuration files can be configured in CUCUMBER.YML files.

    # configuration file definition:
    profile_name:--tags @tag_name

Run a configuration file with instructions:

    Cucumber-p profile_name

If you use fabrication to replace fake data (fixtures), use predefined fabrication steps.

Do not use the old version of the WEB_STEPS.RB step definition! The latest version of Cucumber has removed the web steps, using them to cause redundant scenarios, and it does not correctly reflect the areas of application.

When you examine the visual text of an element, check the text of the element instead of checking the ID. This can detect the problem of i18n.

Create different feature features for the same kind of objects:

  # bad
  feature:articles
  # ... function implementation ...

  # good
  feature:article Editing
  # ... function implementation ...

  Feature:article Publishing ...
  function implementation ...

  Feature:article Search
  # ... Function Implementation ...

Each feature has three main components:
Title
Narrative-brief description of what this feature is about.
Acceptance criteria-each set of scenes consisting of separate steps.

The most common format is called the Connextra format.

  In order to [benefit] ...
  A [Stakeholder] ...
  wants to [feature] ...

This is the most common but not required format, and the description can be any text that relies on functional complexity.

Use the scene overview freely to make your scene ready for it (keep your scenarios DRY).

  Scenario Outline:user cannot register with invalid e-mail when
   I try to register with an email "<email>"
   Th En I should the error message "<error>"

  examples:
   |email     |error         |       | The e-mail is required|
   | Invalid email |is Not a valid e-mail |

The steps of the scene are placed in the. rb file in the Step_definitions directory. The procedure file naming convention is [DESCRIPTION]_STEPS.RB. The steps are placed in different files according to different criteria. Each feature may have a step file (HOME_PAGE_STEPS.RB)
。 It is also possible to create a step file (ARTICLES_STEPS.RB) for each specific object's functionality.

Use multiple-line step parameters to avoid duplication

Scene:

User Profile
   Given I am logged into as a user "John Doe" with a e-mail "user@test.com" when
   I
   Then I should the following information:
    | The name| John     |
    | Last name | Doe     |
    | E-mail  |user@test.com|

  # step:
  Then/^i should the following information:$/do |table|
   Table.raw.each do |field, value|
    Find_field (field). value.should =~/#{value}/
   End
  

Use a composite step to make the scene available for use (Keep your scenarios DRY)

# ...
When I subscribe for news from the category "Technical News"
# ...

Steps
When/^i subscribe for news from the category ([^ ']*) ' $/do |category|
Steps%q{
When I go to the News categories page
And I Select the category #{category}
And I Click the button "Subscribe for this category"
and I confirm the subscription
}
End

Always use capybara negative matches to replace positive situations with Should_not, which retry the match at a given timeout, allowing you to test Ajax actions. See Capybara to read my paper for more instructions.