bdd_cucumber notes
bdd_cucumber notes
Gherkin is a readable business language that allows you to define business activity without
getting bogged down in implementation specifics. It's a domain-specific language for
defining specs tests in Cucumber format. It describes use cases in plain English and helps
users to remove logic elements from behavior testing.
• Feature: The Feature keyword's aim is to collect relevant scenarios and provide a high-
level description of a software feature.
• Rule: The Rule keyword is used to express a single business rule that should be
followed. It adds to the information about a feature.
• Example: This is a practical illustration of a business rule. It comprises a series of steps.
• Given: The given steps are used to describe the system's initial context - the scenario's
scene. It usually refers to an event that occurred in the past.
• When: When describing an occurrence or an action, When is employed. It could be a
user interacting with the system or an event generated by another system.
• Then: Then steps are employed to indicate an anticipated outcome, or result.
• Background: A background helps you to give the situations that follow it some
context. It can have one or more Given steps, which are executed prior to each scenario
but after any Before hooks.
Scenario is a fundamental Gherkin structure. Every scenario begins with the keyword
"Scenario:" (or a localized version of it) and ends with a scenario title. Every feature can have
one or more scenarios, each of which has one or more steps.
Explanation: When a user clicks on the My Orders option he/ she should be taken to the My
Orders page.
Consider the situation when we need to run a test scenario multiple times. Assume we need
to ensure that the login feature is functional for all types of subscribers. This necessitates
repeating the login functionality scenario. Copying and pasting the identical instructions to
just re-run the code does not appear to be a good approach. Gherkin adds another framework,
the scenario outline, to help with this. The scenario outline is similar to scenario, with the
exception that several inputs are provided.
Example:-
Explanation: The website can have multiple users and so we need to consider all the users
while implementing the sign-in functionality.
Here's an example:-
9. What are the basic requirements to run Cucumber Web test cases?
We need the following minimum requirements to successfully run a Cucumber Web test case:
1. The compiler and the development kit for the programming language we will be
using. Example: JDK and JRE for using Java as our programming language.
2. An IDE (Integrated Development Environment) wherein we can write our code.
Example: Eclipse.
3. Build tools so as to do tasks such as compiling code, packaging code to a jar, creating
source code. Example: Maven, Gradle.
Step definitions connect Gherkin steps to programming code. The mapping between each
step of the scenario defined in the feature file and a code of the function to be executed is
stored in the steps definition file. A step definition carries out the action that should be
performed by the step. So step definitions hard-wire the specification to the implementation.
An annotation is a type of text that has been pre-defined and has a specified meaning. It tells
the compiler/interpreter what to do when the program runs. The annotations on Cucumber
are as follows:
• Feature File: It has plain text descriptions of single or numerous test situations.
Keywords like Then, When, Background, Scenario Outline, Feature, And, But, and so
on are used in the tests. As a result, it's a file that keeps track of features and their
descriptions.
• Step Definition File: It has the extension .java. It essentially acts as a translator
between the test scenario steps provided in the feature file and the automation code.
Cucumber searches the step definition file and executes the relevant functions that are
assigned to that step when it runs a step described in the feature file.
• TestRunner: .java is the file extension for this file. It connects the feature file and the
step definition file. It allows the user to run one or more feature files at the same time.
It contains the locations of the step definition and feature files.
14. How do you comment the code in Cucumber? What is the importance of
comments?
A comment is a chunk of code that is intended for documentation rather than execution. To
make it more legible and clearer, whether it is a step definition file or a feature file. As a
result, it is critical to use/insert comments in the right places throughout the file. This is also
beneficial for troubleshooting the code. Comments can be added to Cucumber feature files
at any time. To add comments, simply begin the statement with the “#” sign.
Different programming languages have different standards for commenting. Let's see how
Cucumber handles the situation:
• For Step Definition File, if you're using Java as a platform, start your comments with
"/."
• In the case of a feature file, we only need to type # before starting our comment.
Hooks are code blocks that execute before or after each Cucumber scenario in the execution
cycle. This enables us to better control the development workflow and decrease code
redundancy. Setting up the web driver and terminating the web driver session resembles a
test setup. When dealing with different scenarios, it's best to do the setup and clean up only
once. Hooks are used to bringing optimization.
16. What are tags in Cucumber and why are they important?
When we only have one, two, or maybe five situations in a feature file, it appears to be simple.
In reality, however, this does not occur. In a single feature file, we may have 10, 20, or even
more scenarios for each feature under test. They could reflect various purposes (smoke
test/regression test), perspectives (developer/QA/BA), and statuses (ready for
execution/work in progress).
Tags in cucumber provide a way to run scenarios in a specific sequence from a runner file.
Each situation can be labeled with a useful tag. Later, in the runner file, we may specify
which tag (and hence which scenario(s)) Cucumber should run. “@” is the first character in
a tag. Any relevant content after "@" can be used to define your tag.
Example - ‘@InitialTest’
The purpose of the Cucumber dry run is to verify compilation faults and compile the Step
Definition and Feature files. Dry run's value might be either true or false. Dry run has the
value false by default and it is present in the Test Runner Class file.
If the dry run value is true, Cucumber will check all steps in the Feature file. Within the Step
Definition file, it will also check the implementation code of steps in the Feature file.
If any of the steps in the Feature file is missing its implementation in the Step Definition file,
a message is thrown. The @CucumberOptions has a dry run parameter that is used to
configure the test parameters.
When testing a feature, cucumber profiles make it simple to define groupings of tests in a
feature file so that we can choose to execute only a subset of them rather than all of them. It
was created to help people save time. In a cucumber.yml file, the user can reuse commonly
used cucumber flags.
Cucumber supports a variety of programming languages, including Java, .NET, Ruby, and
others. It can also be used with other tools like Capybara and Selenium.
The Gherkin text serves as a skeleton for your automated tests and serves as documentation. Gherkin
is based on TreeTop Grammar, which is used in more than 37 languages. As a result, you can write
your gherkin in more than 37 different spoken languages.
1. Explain briefly how Behavioral Driven Development works?
There are majorly three steps in the working of BDD. They are as follows:
• Behavior Description: We list down the features of our application first in the feature
file.
• Making the Step Definition file: The mapping between each step of the scenario
defined in the feature file and a code of the function to be executed is stored in the steps
definition file.
• Testing and running: We run the test cases to check if we pass. In general, a lot of
failures are observed before achieving the final code.
The test harness in Cucumber helps in separating the task of establishing the context and
interacting with the browser from cleaning up the step definition files. It gathers the stubs,
drivers, and other tools needed to enable test execution automation in testing.
• To run a set of tests either within the framework or with the help of the test harness
• To enter data into the program being tested.
• Debugging becomes more flexible and supported.
• To record the outputs of the software under test
• To keep track of the test results (pass/fail) for each test.
• Aids developers in determining code coverage at the code level.
RSpec and Cucumber are two examples of testing frameworks. Traditional Unit Testing is
used by RSpec. It refers to the practice of testing a section of an application separately from
the remaining part of the application. As a result, your model performs what it's expected to
do, the controller does what it's expected to do, and so on. Both RSpec and Cucumber are
used for Acceptance Testing, also known as ATDD, BDD, and other terms.
The following are the major differences between RSpec and Cucumber:
• The fundamental distinction between RSpec and Cucumber is the element of business
readability.
• Unit testing is the primary purpose of RSpec. Cucumber, on the other hand, is
primarily utilized in behavior-driven development. It can be used for System and
Integration Testing as well.
• Cucumber separates the specs or features from the test code, allowing product owners
to provide or review the specification without having to walk through the code.
• RSpec includes a similar method, but instead of elaborating a step with a Describe, it
executes the statement using the business specification. This method is easier for
developers to use, but a little more difficult for non-technical people.
Open-source testing tools, Selenium and Cucumber are both used for functional testing.
However, there are some distinctions between them.
Cucumber and Selenium are two widely used testing frameworks and
technologies. Selenium is widely used for functional testing in many organizations. These
companies use Cucumber in conjunction with Selenium because Cucumber makes the
application flow easier to read and comprehend. The most important advantage of combining
Cucumber and Selenium is that it allows developers to build test cases in simple feature files
that managers, non-technical stakeholders, and business analysts can understand. It allows
you to develop tests in Gherkin, a human-readable programming language. Java,.NET, PHP,
Python, Perl, and other programming languages are supported by the Selenium-Cucumber
framework.
A feature file in Cucumber can include a maximum of 10 scenarios. This quantity can differ
from one project to the next and from one organization to the next. It's advisable to keep the
number of scenarios in the feature file to a minimum.
• First, all the test cases are written. Based on your requirements, you must create an
automated test case.
• Carry out all of the tests: Carry out these automated test cases on the code that has been
developed so far.
• Modify the code for that test case: You must develop the code to make that test
casework as intended if it fails throughout this step.
• Rerun the test cases: Now you must rerun the test cases to ensure that all of the
previously developed test cases have been implemented.
• Modularize your code as follows: This is a step that can be skipped. However,
refactoring your code to make it more readable and reusable is recommended. That is
why it is necessary.
• For new test scenarios, repeat steps 1–5: This is the final phase in the process. You must
now repeat the process for the remaining test cases till all of them have been
implemented.
TDD BDD
Test-Driven Development (TDD) is a BDD is an acronym for behavior-driven
method of developing software that is development. It's a behavior-based development
driven by tests. This means that the approach.
developers must first write the test cases
before writing the code.
TDD tests are developed in a variety of Given-When-Then steps are used to write BDD
programming languages, including tests in a human-readable fashion. Non-technical
Java,.NET, Python, Ruby, and others. people may read and comprehend these tests as
well.
The scope is the key distinction between BDD, on the other hand, is a collaborative
TDD and BDD. TDD is a development methodology.
methodology.
When a test fails because the specified Creating an executable specification that fails
function does not exist, TDD because the feature isn't available, then writing
recommends writing the simplest code the simplest code possible to make the spec pass
possible to pass the test, then reworking in BDD. This process is repeated until a release
to remove duplication, and so on. candidate is ready to be delivered.
The test cases are written by the Users or testers write automated specifications
developers in TDD. in BDD, which are then wired to the code under
test by developers.
Because TDD tests are written in specific Non-programmers can read BDD tests since
programming languages, they are they are written in a human-readable format.
difficult to interpret by non-
programmers.
The Options tag is a part of the TestRunner file in the Cucumber framework, and it takes the
form of an annotation named @CucumberOptions.
It has two parameters: glue and feature:
1. Feature: The path to the feature file is specified by the feature option.
2. Glue: The glue argument is used to provide the step definition file's location.
Cucumber execution will begin at the support level. In support, it will first load the env.rb
file, then hooks.rb and last start executing feature file scenario steps.
Cucumber is unconcerned about the names of your step definition files or the order in which
you place them. Instead of maintaining all steps in a single file, we can create steps.rb file
for each major action/feature. This is referred to as grouping.
The Cucumber JVM Parallel Plugin, which may be used with Serenity BDD, can be used to
conduct parallel tests in Cucumber. The plugin will look in the src/test/resources directory
for feature files. After that, it will create runners for each file.
13. What are some of the prerequisites that you should consider while building
a Selenium Cucumber automation application?
• Determine the type of application you will be testing. Is it a Web app, a mobile app, or
a desktop application?
• Is there a need for backend testing? Databases or SDKs, for example.
• Is it necessary to run the app through an internationalization test?
• It must include a report that allows you to track down a problem with minimal effort.
• It must be able to generate parametrization tests automatically.
• Any setup-related settings or global attributes should be defined in a config file.
• To segregate the functionality, use abstraction at every level.
Even though Cucumber and JBehave have the same goal in mind, acceptance tests are two
quite distinct frameworks:
15. How can you run a selected test from a group of tests in Cucumber?
We may execute a single test from a set of tests in the Cucumber framework using the tags
idea. This is found in the TestRunner file's @CucumberOptions section. With the use of the
@t<agname> keyword, we may tag a scenario in the feature file. A scenario can have one or
more tags within the feature file. We can separate test scenarios with the assistance of
tagging. We must pass the <tagname> value within the tags argument to execute a selected
test in Cucumber, and we must pass the <~tagname> value within the tags parameter to
exclude a test from running.
Conclusion:
Cucumber is frequently used in BDD because it is an open-source technology. It's also quite
simple to grasp, has a lot of room for additional features, and it's rather easy to connect
Cucumber with Selenium or other third-party tools/jars, etc.
It is quite easy for anyone who has just started learning Cucumber or for those who have
intermediate experience in Cucumber/BDD because it has active help groups/members.
Cucumber also allows for connectivity with an excel sheet and Jenkins.