A cucumber is a tool that executes plain-text functional descriptions as automated tests. While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. nontechnical stakeholders.
Gherkin is the language used to write features, scenarios, and steps. The purpose of the language is to help us write concrete requirements.
4 Steps in Defining a Feature
- Cucumber begins by defining a “Feature” that we are trying to implement.
- After that, we specify what we want to do using “In Order”.
- We specify a user who will be interacting with that feature using “As a”
- And then we finally specify what do we expect using “I want”
Feature: User login In order to log in As a User I want to specify a valid credential and login
- Cucumber internally uses capybara
- You can use any other acceptance test framework e.g. Webrat
- Capybara makes it possible to restrict certain actions, such as interacting with forms or clicking links and buttons, to within a specific area of the page
- You can use within DSL to specify a scope e.g. within(“#form-group”)
- You can also further restrict it to a table e.g. within_table(“customer-table”)