Cucumber 01
Cucumber 01
Cucumber 01
Learn how modern cloud architectures use of microservices has many advantages and enables developers
to deliver business software in a CI/CD way. Integration test cases are expected to be executed after
deployment on QA environments on microservices. We can create a separate microservice integration test
module to run integration test cases of any microservices and execute on QA deployment. It can be
configured with the build pipeline using Jenkins, Bamboo, etc. When the build will be passed after BDD
integration is run on QA, then it should be promoted to the staging/pre-prod environment to make sure that
all the REST APIs are intact. Objective This article will describe current challenges, usage of Cucumber
JVM BDD in agile development, setup with Spring Boot, and Jenkins integration. Cucumber has very
powerful reporting with graphs and tables, which can be integrated with Jenkins and share the report. It also
generates JSON reports, which can be integrated with other applications or integration testing. It simplifies
behavioral testing by using a simple English-like language that can be written by business/QA (non-
developers) and later converted to a technical integration test case with or without mocking. Why BDD?
BDD (Behavior Driven Development) is a methodology for developing software through continuous
interaction between developers, QAs, and BAs within the agile team. BDD has these major components: *
Feature file: It contains feature info like scenarios, steps, and examples (test data). It's written in Gherkin.
It's a plain text file with the ".feature" extension.
* Scenario: Every feature can have multiple positive and
negative test scenarios — for example, login with the wrong password, login with the correct login
credentials, etc.
* Step Definitions: Every scenario contains a list of steps.
Given-When-Then BDD is based
on these three major pillars: 1. Given: Precondition. 2. When: Test execution. 3. Then: Acceptance and
assertions. Reference: https://github.com/cucumber/cucumber/wiki/Given-When-Then. Cucumber doesn’t
technically distinguish between these three kinds of steps. Given The purpose of Givens is to put the
system in a known state before the user (or external system) starts interacting with the system (in the When
steps). Avoid talking about user interaction in Givens. If you were creating use cases, Givens would be your
preconditions. Examples 1. Setting up initial data 2. Setting up the initial configuration 3. Creating model
instances When The purpose of When steps are to describe the key action the user performs, such as
interacting with a web page. It actually calls the business logic or actual APIs. Then The purpose of Then
steps is to observe outcomes like JUnit assertions. The observations should be related to the business
value/benefit in your feature description. The observations should also be on some kind of output
(calculated value, report, user interface, message). Examples * Testing REST APIs or test execution.
*
Verifying that something related to the Given+When is (or is not) in the output.
* Checking that
some external system has received the expected message.
And, But If you have several Givens, Whens, or
Thens, you can write like this:
1. Simplicity: No-technical syntax of features files. Features files are written in plain English, which can be
linked with Agile stories. 2. Communication between business and development is extremely focused as a
result of a common English-type language. 3. The code is easier to maintain, flexible, and extendable. 4.
The code is self-documenting with the examples. 5. Test data can be changed only in the features file, not
in the code. 6. Stories are easier to “groom” – breakdown, task, and plan. 7. There is more visibility into
team progress and status using reports. Cucumber reports can be shared with top level management,
integrated with Jenkins and configured with email notifications. It can also be integrated with automated
build and deployment tools like Jenkins email plugins. Unit Testing vs. TDD vs. BDD Unit testing is for
testing individual modules, whereas TDD is based on writing test cases first and then writing code to make
that pass. BDD is based on the behavioral testing based on real scenarios (which can't be tested in TDD).
Testing microservices REST APIs are a good example. Reference: This article has detail comparison matrix
with other BDD tools: https://codeutopia.net/blog/2015/03/01/unit-testing -tdd-and-bdd/. Why BDD with
Cucumber? Pros/Cons: Note: Please refer this comparison reference with other BDD
tools/APIs: https://dzone.com/articles/brief-comparison-bdd. Cucumber is a very powerful framework for
BDD testing. It has many useful features like testing by example (data tables, which can be part of the test
cases ) or parameters, which can be passed directly from feature file(s). Multiple sets of tests can be sent to
BDD test cases. Test data can be passed from the feature files without touching code or making changes in
properties resource files. Features files and the related code looks readable and maintainable. Additionally,
Cucumber supports many different languages and platforms like Ruby, Java, or .NET. Getting Started With
Cucumber Cucumber setup with SpringBoot, RestAssured, AssertJ, and JSONAssert. This sample
code/POC is developed using Cucumber with SpringBoot v1.5.1, RestAssured v3.0.3, AssertJ and Java 8.
Cucumber Maven Dependencies:
org.springframework.boot
spring-boot-starter-web</artifac
tId>
org.springframework.boot
spring-boot-starter-test</artifa
ctId>
org.springframework.boot
spring-boot-devtools
true
info.cukes
cucumber-spring
${cucumber.version}
io.rest-assured
rest-assured
${restassured.version}
info.cukes
cucumber-junit
${cucumber.version}
test
info.cukes
cucumber-java
${cucumber.version}
test
org.springframework
spring-tx
com.googlecode.json-simple
json-simple
com.jayway.jsonpath
json-path-assert
test
Feature file:
@signupServices
Feature: Cucumber - SignUp Services
Integration Test
Examples:
|api_key | userId |
password | client_id|
| test************ | password |
Advanced Reporting Dashboard Run Cucumber Test Cases From the Command Line To run Cucumber
from the command line, you need to add this Maven plug-in.
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
<includes>
<exclude>**/*CucumberRunner.java</exclude>
</includes>
</configuration>
Test Suite Using Cucumber Cucumber has a feature to group features/scenarios as a group, which is called
a "tag". It can be annotated in the feature file by using @, for example, @signupServices. These test suites
can be run individually based on your requirements.
-Dspring.profiles.active=dev
@signupServices,@loyaltyService" -Dspring.profiles.active=dev
-Dspring.profiles.active=dev
Cucumber Jenkin Integration Please refer these links to configure with Jenkin. *
https://github.com/jenkinsci/cucumber-reports-plugin
* https://www.youtube.com/watch?v=ceRnV0C3pDw