Explain how to use Cucumber in Ruby on Rails, railscucumber

Explain how to use Cucumber in Ruby on Rails, railscucumber

Use the @ wip label to mark your unfinished scenarios. These scenarios are not considered and are not marked as test failures. When an unfinished scenario is completed and the function test passes, the @ wip tag should be removed to add the scenario to the test suite.
Configure your default configuration file to exclude the scenes marked as @ javascript. They are tested using a browser. We recommend that you disable them to increase the execution speed in general scenarios.

Configure another configuration file for the scenario marked with @ javascript.

The configuration file can be configured in the cucumber. yml file.

# Definition of the configuration file:
     profile_name: --tags @tag_name

Run a configuration file with commands:

    cucumber -p profile_name

If fabrication is used to replace false data (fixtures), use the predefined fabrication steps.

Do not use the old web_steps.rb step definition! The latest version of Cucumber has removed web steps, which leads to redundant scenarios and does not correctly reflect the application fields.

When checking the visual text of an element, check the text of the element instead of the id. In this way, the i18n problem can be found.

Create different features for objects of the same type:

# Poor
   Feature: Articles
   # ... Function Implementation ...

   # it is good
   Feature: Article Editing
   # ... Function Implementation ...

   Feature: Article Publishing
   # ... Function Implementation ...

   Feature: Article Search
   # ... Function Implementation ...

Each function has three main components:
Title
Narrative-briefly describes what this feature is about.
Acceptance criteria-a set of scenarios composed of independent steps.

The most common format is Connextra.

 In order to [benefit] ...
  A [stakeholder]...
  Wants to [feature] ...

This is the most common but not the required format. The description can be any text that depends on the complexity of the function.

Use scenario overview freely for your scenario backup (keep your scenarios DRY ).

 

Scenario Outline: User cannot register with invalid e-mail
   When I try to register with an email "<email>"
   Then I should see the error message "<error>"

  Examples:
   |email     |error         |
   |       |The e-mail is required|
   |invalid email |is not a valid e-mail |


 

	
  


 

The steps of the scenario are stored in the. rb file in the step_definitions directory. The naming convention for Step files is [description] _ steps. rb. The steps are stored in different files according to different standards. Each function may have a step file (home_page_steps.rb)
. You may also create a step file (articles_steps.rb) for the function of each specific object ).

Use multi-line parameters to avoid duplication

Scenario:

User profile
    Given I am logged in as a user "John Doe" with an e-mail "user@test.com"
    When I go to my profile
    Then I should see the following information:
     | First name | John |
     | Last name | Doe |
     | E-mail | user@test.com |

   # Step:
   Then / ^ I should see the following information: $ / do | table |
    table.raw.each do | field, value |
     find_field (field) .value.should = ~ / # {value} /
    end
   end 

Use compound steps for scenario backup (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 subtasks
}
End

Always use Capybara to replace should_not in the front case. They will retry the matching at a given timeout, allowing you to test the ajax action. For more information about how to read my files from capybench.