Cucumber Interview Questions Testing

“And” is used to combine two or more same type of action.

Cucumber steps beginning with “And” or “But” are exactly the same as all other steps.

Example:

      Given one thing

      And another thing

      When I open my eyes

      Then I see something

      But I don't see something else

Cucumber allows you to precede Feature and Scenario keywords with comments.

Comments will be denoted with #

Example

# This is a feature

Feature: Adding

# This is Scenario

Scenario: Add two numbers

Given……..

Cucumber will not take care how you name your step definition files and what step definitions you put in which file.

You can create steps.rb file for each Major operation / Features instead of keeping all steps in a single file. This process is called a grouping.

Example

Under features folder

• Adding_steps.rb
• Multiplying_steps.rb

Tags are the sticky notes you’ve put on pages you want to be able to find easily. 

You tag a scenario by putting a word prefixed with the @ character on the line before the Scenario keyword.

If you want to tag all the scenarios in a feature at once, just tag the Feature element at the top, and all the scenarios will inherit the tag.

You can attach multiple tags to the same scenario, separated with spaces.

Example

@adding @two @numbers

Feature: Adding

@add 

Scenario Outline: Add two numbers

You can generate the output/report of the cucumber using different cucumber commands.

>cucumber adding.feature --format HTML 

>cucumber adding.feature --out report.html 

>cucumber adding.feature --format pretty

The report file will be stored in the project folder itself.

Step definition maps the test case steps in the feature files(introduced by Given/When/Then) to code which executes and checks the outcomes from the system under test.

A step definition is analogous to a method defined in any kind of Object Oriented programming language.

Step definition is defined in ruby files under features/step_definitions/*_steps.rb".

Ansicon is used to give colored output for features, Step definitions, Errors, and test results.

Download the ansicon and select 32 bit/64 bit depends upon your system configuration.

Cucumber supports over 40 spoken languages and the number is still growing.

Using the #language: header, you can write your features in different spoken languages. 

Add it on the first line of a feature file will tell us which spoken language cucumber is using.

Example

# language: en

Feature: This is Feature title

When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green).

When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped.

When a Step Definition’s Proc invokes the pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do.

Steps that follow undefined, pending or failed steps are never executed (even if there is a matching Step Definition) and are marked cyan.  

You can use report tools like Jenkins or bamboo tool.

Behavior-driven development – in short BDD

Behavior-driven development combines the general techniques and principles of TDD to provide software development and management teams with shared tools and a shared process to collaborate on software development.

TDD practitioners work from the outside-in, starting with a failing customer acceptance test that describes the behavior of the system from the customer’s point of view.

Cucumber is a tool based on Behavior Driven Development (BDD) framework which is used to write acceptance tests for a web application. It is written in Ruby.

It allows automation of functional validation in an easily readable and understandable format like plain English. Cucumber can be used along with Selenium, Watir, and Capybara etc.

Cucumber supports many other languages like Perl, PHP, Python, Java etc.

A cucumber is a command-line tool. When you run it, 

• It reads in your specifications from plain-language text files called features files.
• Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code.
• Once all the steps are added run the cucumber again to get the passed test cases or failed test cases.
• Repeat the steps until all the test cases are being passed.

Cucumber tool has a lot of advantages.

• It is helpful to involve business stakeholders who can't easily read a code.
• Cucumber focuses on end-user experience.
• Style of writing tests allows for easier reuse of code in the tests.
• Quick and easy setup and execution.
• An efficient tool for testing

• features - folder has all .feature files
• step_definitions - folder has all step definitions files
• support – folder has all the supported modules/libraries/files
• Gemfile - list of Rubygems(optional)
• Test results – folder has all the reports generated(optional)

Cucumber tests are grouped into features. Features give information about the high-level business functionality and the purpose of Application under test. Feature files are get stored here.

Feature folder has two subfolders

• step_definitions - folder has all step definitions files
• support – folder has all the supported modules/libraries/files 

Feature files are an essential part of cucumber which is used to write test automation steps or acceptance tests. This can be used as a live document. The steps are the application specification. All the feature files end with .feature extension.

Cucumber uses expressions to link a Gherkin Step to a Step Definition. You can use Regular Expressions or Cucumber Expressions.

Regular expressions are handy to filter/find a specific matching pattern in any text.  

Cucumber Expressions offer similar functionality to Regular Expressions, with a syntax that is easier to read and write.

what to do. By seeing the scenario user should be able to understand the intent behind the scenario and what the test is all about.

Each scenario should follow given, when and then format.

Example

Feature: Subtraction

Scenario: Subtracting two numbers

Gherkin is the language that Cucumber uses to define test cases. It is designed to be non-technical and human-readable, and collectively describes use cases relating to a software system. It is a Business Readable, Domain Specific Language (DSL).

Gherkin gives two purposes in Cucumber

• Documentation 
• Automated tests.

A Gherkin file is given its structure and meaning using a set of special keywords.

• Feature
• Background, Scenario, Scenario Outline
• Given
• When
• Then
• And, But
• Examples

Scenario outline is a way of parameterization of scenarios. Scenario outlines are used when the same test has to be performed with different data set, however, the test steps remain the same. 

Scenario Outline must be followed by the keyword ‘Examples’, which specify the set of values for each parameter.

Example

Feature: Subtracting

Scenario Outline: Subtracting any two numbers

Whenever any step is required to perform in each scenario then those steps need to be placed in Background. Background generally has the instruction on what to set up before each scenario runs.

Feature: Subtracting

Background: The calculator should be reset to 0.

Scenario Outline: Subtracting two numbers

“Given” specifies the pre-conditions. It is basically a known state.

The purpose of givens is to put the system in a known state before the user starts interacting with the system.

Example

Given the input "<input>"

When the calculator is run

Then the output should be "<output>"

The purpose of “When” is to describe the key action the user performs.

In other words “When” is used when some action is to be performed.

Example

Given the input "<input>"

When the calculator is run

Then the output should be "<output>"

The expected outcome or result should be placed here. The purpose of “Then” steps is to observe outcomes. The observations should be related to the business value/benefit in your feature description. The observations should also be on some kind of output.

Example

Given the input "<input>"

When the calculator is run

Then the output should be "<output>"