 |
VOOZH | about |
|
VOOZH | about |
Cucumber is a widely used BDD testing tool for automating software tests. It allows teams to write test cases in simple language, making testing easy to understand and manage.
This section covers commonly asked Cucumber interview questions for freshers, including BDD concepts, Gherkin syntax, scenarios, and Cucumber integration with testing frameworks.
Cucumber is a testing tool that helps you write and run software tests. It follows a method called Behavior Driven Development (BDD). With Cucumber, you can write tests in plain English, so even people who are not technical can understand them.
The main principle of Behavior-Driven Development (BDD) is to improve collaboration between developers, testers, and business analysts. It uses simple and understandable language to describe software behavior, ensuring everyone clearly understands the requirements and expected outcomes.
To work with Cucumber, you should know these basic concepts:
A scenario in Cucumber is a single test case that represents a specific functionality or user action in the application. It contains steps that define actions and expected results.
Gherkin is the language used to write Cucumber tests. It uses plain English to describe software behavior in a way that everyone can understand. Gherkin uses keywords like "Feature," "Scenario," "Given," "When," and "Then" to organize test steps, making it easy for both technical and non-technical people to read and write tests.
A Scenario Outline in Cucumber is used to run the same test scenario with multiple sets of data. It allows reusable test steps by using different input values from the Examples table.
A feature in Cucumber is a high-level description of a software functionality. It is written in a .feature file and contains scenarios that describe how the feature should behave.
Cucumber helps with several tasks in software development:
To test an API in Cucumber, you first write feature files in Gherkin language to describe API behavior. Then, step definitions are implemented to send API requests using tools like RestAssured or requests.
Debugging in Cucumber involves finding and fixing issues in your Cucumber tests or the code they test. Common debugging methods include:
In Cucumber, steps are individual actions or validations written in plain English within a scenario. They use keywords like Given, When, Then, And, and But.
Annotations in Cucumber are special keywords or symbols used in the step definition files to mark specific methods. They help Cucumber understand how to connect the steps written in the feature files with the corresponding code. Common annotations include:
Hooks in Cucumber are blocks of code that run at specific points during the test execution cycle. They help manage setup and teardown tasks. You can use hooks to perform actions like opening a browser, setting up test data, or cleaning up after tests.
Tags in Cucumber are labels that you can add to your scenarios or features to organize and control which tests to run. They are written with the "@" symbol followed by a tag name, like @smokeTest or @regression.
Tags are important because they allow you to:
For example:
@smokeTest
Scenario: Verify user login
Given the user is on the login page
When the user enters valid credentials
Then the user is redirected to the homepage
A Dry Run in Cucumber is a special mode that checks whether all the steps in the feature files have corresponding step definitions without actually executing the tests. It helps identify missing or undefined steps.
dryRun = true in Cucumber optionsWhen you run this, Cucumber will validate the steps and report any missing step definitions.
Cucumber parameters allow you to pass dynamic values to your steps. They make your scenarios more flexible and reusable. You define parameters using angle brackets < > in your feature files, and then capture these values in your step definitions.
Example:
Scenario: User logs in
Given the user logs in with username "<username>" and password "<password>"
Step Definition:
A Cucumber profile is a way to group and run a specific set of tests with certain configurations. You can define profiles in a cucumber.yml file, and each profile can have different settings like tags to include or exclude, paths to feature files, and other options.
Example cucumber.yml:
default: --tags @regression --glue stepDefinitions --plugin pretty
smoke: --tags @smokeTest --glue stepDefinitions --plugin pretty
To run tests with a specific profile, use the --profile option:
cucumber --profile smoke
Cucumber was originally written in the Ruby programming language. However, it has since been implemented in several other languages, including Java and JavaScript, to support a wider range of developers.
Cucumber uses Gherkin, a simple, plain-text language that describes the behavior of software. Gherkin uses keywords like Feature, Scenario, Given, When, Then, And, and But to write tests that are easy to read and understand for both technical and non-technical people.
To execute a Cucumber test scenario, two main files are required:
A. Feature File (.feature): This file contains the high-level description of the software feature and the test scenarios written in Gherkin language. Example:
Feature: User Login
Scenario: Successful login with valid credentials
Given the user is on the login page
When the user enters valid username and password
Then the user should be redirected to the homepage
B:Step Definition File: This file contains the code that implements the steps defined in the feature file. The step definitions link the Gherkin steps to actual code. Example:
Cucumber uses several keywords in Gherkin to write scenarios. These keywords help to describe the behavior of the software:
The Background keyword in Cucumber is used to define steps that are common to all scenarios in a feature file. It helps avoid repetition by running the same setup steps before each scenario.
Example:
Feature: User Login
Background:
Given the user is on the login pageScenario: Successful login
When the user enters valid credentials
Then the user should be redirected to the homepageScenario: Unsuccessful login
When the user enters invalid credentials
Then the user should see an error message
A step definition in Cucumber is the code implementation for the steps written in a feature file. It connects Gherkin steps with automation code that performs the actual actions.
Example: Given the user is on the login page
Step Definition in Java:
Cucumber supports multiple programming languages, making it versatile for different development environments. The supported languages include:
JBehave vs Cucumber
| Feature | Cucumber | JBehave |
|---|---|---|
| Language Support | Supports multiple languages like Java, Python, Ruby, JavaScript | Mainly focused on Java |
| Syntax | Uses Gherkin language | Uses story-based syntax |
| Ease of Use | More user-friendly and readable | Slightly more technical |
| Community Support | Large community and wide adoption | Smaller community support |
| Readability | Easy for technical and non-technical users | Mainly developer-focused |
| Integration | Works with JUnit, TestNG, Selenium, etc. | Mainly integrates with Java frameworks |
Regular expressions (regex) are patterns used to match character combinations in strings. They are used for searching, manipulating, and editing text based on specific patterns. In Cucumber, regular expressions are often used in step definitions to match steps in feature files and extract values dynamically.
Example: Given the user enters "John" as the username
Step Definition with Regex:
In this example, \"([^\"]*)\" is a regular expression that captures the username from the step.
To run a Cucumber web test case, the following software and tools are commonly used:
A test harness in Cucumber is a set of tools and libraries that work together to automate the execution of test scenarios. It includes the following components:
The main aim of Behavior Driven Development (BDD) is to improve communication and collaboration between all stakeholders such as developers, testers, and business analysts. It uses a common language (Gherkin) to describe application behavior, ensuring that everyone clearly understands requirements and the software meets business needs.
In the real world, the purpose of Behavior Driven Development (BDD) is to:
Test-Driven Development (TDD) is a software development approach where you write tests for your code before you write the code itself. The process helps ensure that the code is working as expected and helps in creating cleaner, more reliable code.
Processes used in TDD:
Similarities between BDD and TDD:
| Feature | TDD (Test Driven Development) | BDD (Behavior Driven Development) |
|---|---|---|
| Focus | Internal code implementation | Application behavior |
| Language | Programming language (Java, etc.) | Simple natural language (Gherkin) |
| Stakeholders | Mainly developers | Developers, testers, business users |
| Purpose | Ensure code correctness | Ensure business requirements are met |
| Test Style | Unit tests | Scenario-based tests |
| Readability | Technical and less readable | Easy to understand for non-technical users |
| Approach | Write test → write code → refactor | Define behavior → write scenarios → implement code |
The Given step in Cucumber is used to describe the initial context or state before an action is taken in a test scenario. It sets up the preconditions for the test. The Given step helps establish the context for the scenario by providing background information or setting up necessary conditions.
Example: Given the user is on the login page
The When step in Cucumber describes the action or event that triggers the test scenario. It represents the main action that the user or system performs. The When step is used to specify the action that will be tested.
Example: When the user enters valid credentials and clicks the login button
The Then step in Cucumber is used to specify the expected outcome or result of the action performed in the When step. It checks if the system behaves as expected after the action has taken place. The Then step is where assertions and validations are made to ensure the software is working correctly.
Example: Then the user should be redirected to the homepage
Background and Scenario Outline in Cucumber:
| Feature | Background | Scenario Outline |
|---|---|---|
| Purpose | Used to define common steps for all scenarios in a feature file | Used to run the same scenario multiple times with different data |
| Execution | Runs before every scenario | Runs once per data row in Examples table |
| Data Usage | Does not use data tables | Uses Examples table for multiple inputs |
| Reusability | Avoids repetition of setup steps | Avoids repetition of test scenarios |
| Example Use | Login page setup for all scenarios | Testing login with multiple usernames/passwords |
A tag in Cucumber is a label that you can assign to scenarios or features to organize and control which tests to run. Tags are prefixed with the @ symbol and are used to filter and group tests based on their purpose, type, or other criteria.
Example:
@smokeTest
Scenario: Verify user login
Given the user is on the login page
When the user enters valid credentials
Then the user should be redirected to the homepage
The purpose of a Cucumber tag is to:
Example usage:
cucumber --tags @smokeTest
The purpose of using regular expressions (regex) in Cucumber is to:
Example: Given the user enters "John" as the username
Step Definition with Regex:
In this example, the regular expression \"([^\"]*)\" captures the username from the step and passes it to the enterUsername method
A Data Table in Cucumber is used to pass multiple values or sets of data to a single step in a feature file. It helps in handling large or structured test data in a readable format.
Example:
Scenario: Verify user details
Given the following user details:
| name | email | age |
| John | john@example.com | 30 |
| Jane | jane@example.com | 25 |
Step Definition:
The Background keyword in Cucumber is used to define a set of common steps that should be run before each scenario in a feature file. It helps avoid repetition by specifying steps that all scenarios in the feature share. The Background steps are executed before each scenario, ensuring a consistent starting point.
Example:
Feature: User Login
Background:
Given the user is on the login page
Scenario: Successful login
When the user enters valid credentials
Then the user should be redirected to the homepage
Scenario: Unsuccessful login
When the user enters invalid credentials
Then the user should see an error message
You can skip a scenario in Cucumber by using tags. By tagging a scenario with a specific tag (e.g., @skip), you can configure your test runner to exclude scenarios with that tag during execution.
Example:
@skip
Scenario: This scenario will be skipped
Given some precondition
When some action is taken
Then some expected result is obtained
In your test runner, exclude the @skip tag:
cucumber --tags "not @skip"
To generate HTML reports in Cucumber, you need to use a reporting plugin. The cucumber-html-reporter is a popular choice. You configure your test runner to generate the report.
Example in Java with Maven and Cucumber:
A. Add the required dependencies to your pom.xml:
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<version>6.10.4</version>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>6.10.4</version>
</dependency>
B. Configure the @CucumberOptions annotation in your test runner:
C. Run your tests. The HTML report will be generated in the target/cucumber-reports.html file.
A Cucumber report is a generated output that shows the results of test execution in a readable format. It provides details about passed, failed, and skipped scenarios in Cucumber test runs.
A Cucumber feature is a high-level description of a functionality of an application written in a .feature file using Gherkin language. It describes system behavior in plain English and serves as both documentation and executable test cases.
It contains one or more scenarios that define different use cases of the feature.
A Cucumber plugin is an extension that adds additional functionality to Cucumber. Plugins can be used to generate reports, integrate with other tools, and extend Cucumber's capabilities. Commonly used plugins include those for generating HTML reports, JSON reports, and integrating with Continuous Integration (CI) tools.
Example configuration for using the HTML report plugin:
A Cucumber Scenario Outline is used to run the same scenario multiple times with different sets of input data. The Scenario Outline uses placeholders in the scenario steps, and the actual data is provided in an Examples table.
Example:
Feature: User Login
Scenario Outline: Successful login with valid credentials
Given the user is on the login page
When the user enters "<username>" and "<password>"
Then the user should be redirected to the homepage
Examples:
| username | password |
| user1 | pass1 |
| user2 | pass2 |
| user3 | pass3 |
In this example, the Scenario Outline will run three times, once for each set of values in the Examples table.
A Cucumber step is an individual line in a scenario that describes a specific action or condition in plain English. Each step represents part of the test flow and is executed through a corresponding step definition in code.
Example:
Given the user is on the login page
When the user enters valid username and password
Then the user should be redirected to the homepage
Corresponding step definitions:
A Cucumber test is a behavior-driven test written in plain English using Gherkin language to describe how an application should behave. It is executed using Cucumber and step definitions to automate the validation of application functionality.
.feature files using Gherkin Example:
Scenario: Successful login
Given the user is on the login page
When the user enters valid credentials
Then the user is redirected to the homepage
In Cucumber, a world is a context object that holds shared state and data between different steps in a scenario. It allows you to maintain and access common information throughout the scenario execution. The world is typically used to store data that needs to be accessed by multiple step definitions, helping to avoid global variables and keep the code clean.
Here is the difference between Feature and Scenario in Cucumber:
| Feature | Scenario |
|---|---|
| Represents a high-level functionality of the application | Represents a specific test case or example |
| Contains one or more scenarios | Contains steps (Given, When, Then) |
| Written in .feature file using Gherkin | Written inside a feature file under a feature |
| Describes what is being tested | Describes how a specific case is tested |
| Example: User Login feature | Example: Successful login scenario |
Here is the difference between Scenario and Step in Cucumber:
| Scenario | Step |
|---|---|
| A complete test case that describes a specific behavior of the application | A single action or validation within a scenario |
| Contains multiple steps | Is a part of a scenario |
| Written using Given-When-Then structure | Written using keywords like Given, When, Then, And, But |
| Represents what needs to be tested | Represents how the test is performed step by step |
| Example: User login test case | Example: “Given the user is on the login page” |
Here is the difference between JUnit and Cucumber:
| JUnit | Cucumber |
|---|---|
| A unit testing framework for Java | A BDD (Behavior Driven Development) testing tool |
| Used mainly for testing code logic | Used for testing application behavior |
| Tests are written in Java code | Tests are written in plain English (Gherkin) |
| Mainly used by developers | Used by developers, testers, and business teams |
| Focuses on unit and functional testing | Focuses on behavior-driven testing |
| Example: @Test methods | Example: Given-When-Then scenarios |
Here is the difference between RSpec and Cucumber:
| RSpec | Cucumber |
|---|---|
| A testing framework mainly used for Ruby | A BDD (Behavior Driven Development) tool |
| Tests are written in Ruby code | Tests are written in plain English (Gherkin language) |
| Focuses on unit and behavior testing at code level | Focuses on application behavior from user perspective |
| Mainly used by developers | Used by developers, testers, and business teams |
| More technical and code-oriented | More readable and business-friendly |
Example: expect(result).to eq(10) | Example: Given-When-Then scenarios |
The purpose of using Cucumber is to support Behavior Driven Development (BDD) by writing test cases in simple, human-readable language that describes how an application should behave.
To debug a Cucumber test, you can follow these steps:
dryRun = true to check for missing step definitions without executing tests To debug failing Cucumber tests, follow these steps:
Here is the difference between Soft Assertion and Hard Assertion in Cucumber (used via testing frameworks like TestNG/JUnit):
| Hard Assertion | Soft Assertion |
|---|---|
| Stops execution immediately when an assertion fails | Continues execution even if an assertion fails |
| Used when failure should block further steps | Used when you want to check multiple validations in one run |
Example: Assert.assertEquals() | Example: SoftAssert.assertEquals() |
| Provides immediate failure feedback | Collects all failures and reports at the end |
| Commonly used in critical validations | Useful for validating multiple conditions |
Cucumber hooks are used to perform actions before or after scenarios, features, or steps. They help set up preconditions and clean up after tests. Commonly used hooks are @Before and @After.
Example in Java:
To use Cucumber with Selenium, you need to follow these steps:
A. Set Up Dependencies:
Add the required dependencies for Cucumber and Selenium in your build file (e.g., pom.xml for Maven or build.gradle for Gradle).
Example pom.xml:
<dependencies>
<!-- Cucumber dependencies -->
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-java</artifactId>
<version>6.10.4</version>
</dependency>
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>6.10.4</version>
</dependency>
<!-- Selenium dependency -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.141.59</version>
</dependency>
</dependencies>
B. Create Feature Files:
Write feature files in Gherkin syntax to describe the behavior of your application.
Example Login.feature:
Feature: User Login
Scenario: Successful login with valid credentials
Given the user is on the login page
When the user enters valid username and password
Then the user should be redirected to the homepage
C. Write Step Definitions:
Implement step definitions in Java to map Gherkin steps to Selenium code.
Example LoginSteps.java:
C. Run Tests:
Create a test runner class to run your Cucumber tests.
Example TestRunner.java:
D. Execute Tests:
Run the test runner class to execute the Cucumber tests with Selenium.
In Cucumber, grouping refers to the organization of related scenarios or steps to make the test suite more manageable and readable. This can be achieved using tags and different folders for feature files and step definitions.
A. Using Tags:
Tags can be used to group related scenarios for easier execution and management.
Example:
@smokeTest
Scenario: Successful login
Given the user is on the login page
When the user enters valid username and password
Then the user should be redirected to the homepage
@regressionTest
Scenario: Unsuccessful login
Given the user is on the login page
When the user enters invalid username and password
Then the user should see an error message
B. Organizing Feature Files:
Place feature files in directories based on functionality or modules.
Example directory structure:
src/test/resources/features
├── login
│ └── Login.feature
├── registration
│ └── Registration.feature
C. Organizing Step Definitions:
Group step definitions in packages based on functionality or feature.
Example:
There is no fixed rule, but as a best practice, a feature file should contain:
Best practices: