Quick Refresh : Introduction to Cucumber And JBehave to Cucumber Migration
Introduction to Cucumber:
- Cucumber is a software testing tool that allows development teams to create software by writing “executable specifications” and create systems from the “outside-in”. In doing so, we can ensure that what we deliver, along with the quality of what we deliver, meets the expectations of the business stakeholders
- Cucumber introduces the notion of “features” which describe the behavior you wish to test. The feature is then broken down into a number of different “scenarios” which comprise the test you wish to execute which will subsequently validate the feature. Each scenario is further broken down into a number of “steps” which describe the execution path of each scenario. Typically, these follow a strict “given-when-then” format which aids consistency and provides a clear template for writing acceptance tests.
- Cucumber-JVM is a Java-based variant of Cucumber.
Benefits of Cucumber over JBehave:
- Reliable Eclipse plug-in support, reducing development time and increasing usability
- Ability to tag scenarios and run independently (for example tagging scenarios with @Fx and running these only)
- Colored console output, enhancing readability of tests
- Simpler integration into our Continuous Integration (CI) environment
- Extensive community, books, resources, and software plug-in
- Browser test automation support, allowing us to use Selenium or similar tooling to test an HTML5 front-end
The drawbacks of Using Cucumber over JBehave:
¡ Autocomplete feature doesn’t work in with cucumber eclipse plug-in.
¡ Cucumber generated reports are very plain HTML. It is not as fancy as Jbehave reports.
¡ Cucumber Reports are not looking good from perspective but good thing is cucumber feature can be run as JUnit and in JUnit Runner view you can see each Step passing / failing / pending.
Cucumber Eclipse Plug-in
¡ Cucumber Eclipse plug-in: Open Help->Install new software, and put this URL into the “Work With” box: http://cucumber.github.
Select and install the Cucumber Eclipse plugin
Select and install the Cucumber Eclipse plugin
¡ ANSI Console Eclipse plug-in: This beautifies output from Cucumber when running tests, providing syntax highlighting and indentation. On GitHub, at https://github.com/mihnita/
Maven Dependencies:
<dependency>
<groupId>info.cukes</groupId>
<artifactId>cucumber-java</
<version>1.2.0</version>
<scope>test</scope>
</dependency>
<dependency>
</dependency>
<dependency>
</dependency>
Migrating Jbehave Story to Cucumber Story:
1) Notice that in Cucumber Stories we need to mention values in single quotes.
2) Eclipse plug-in options-
II. Right click option – Find Option
III. Run As – Cucumber Feature.
Migrating Jbehave Steps to Cucumber Feature
Jbehave :
@When("I receive a trade message with a price of $price")
public void receiveTradeWithPrice(String price)
{
//Some Logic
}
Cucumber:
@When("^I receive a trade message with a price of '(.*)'$")
public void receiveTradeWithPrice(String price)
{
//Some Logic
}
Tips:
• Do not forget to replace JBehave imports to cucumber imports.
• If you have parameters in your step statement then you need to start step statement with ^ and end with $.
• Cucumber does not have anything equivalent to JBehave’s @Alias so we need to put either put the logic in common method and need to call it from separate Given/When/Then statement or use @And annotation.
Cucumber Annotation - @Before, @After: Executed before or after each scenario.
@Before
public void before()
{
init ();
}
@After
public void after()
{
cleanup();
}
Tip: If you need to use some autowired class in a @Before annotated method then you need to add src/test/resource/cucumber.xml which imports your applicationcontext.xml
Create the JUnit Cucumber Test Runner:
@RunWith(Cucumber.class)
@CucumberOptions(
features = "src/test/resources/features/"
format = {"pretty", "html:target/cucumber"},
strict = true,
tags = { "~@Ignore", "~@Unimplemented"})
public class CucumberTest
{
}
¡ Note that the content of this class is empty – it serves only to associate JUnit with our Cucumber specifications.
Cucumber Annotation -@Format:
¡ Given the current business date is '15/MAR/2013‘
@Given("^the current business date is '(.*)'$“)
public void givenCurrentBusDateIs(@Format(
{
_busDate = currentBusDate;
}
@CucumberOptions
Cucumber-JVM: All you need to know about @CucumberOptions
When we talk about Cucumber JVM for Behavior Driven development, we often talk about Feature files, Scenarios, Background and Glue code(step definitions). There is no iota of doubt that you cant implement BDD untill you know the concepts mentioned above but other area that is really important and is very useful in day to day BDD life is @CucumberOptions.
Lets start by understanding the structure of the cucumber project i am going to use in examples.Here is the snapshot for project structure.
To simplify the learning process, i have divided the blog in 3 parts:
· Usage of @CucumberOptions
· How to use it ( code part)
· Different options available
Usage: @CucumberOptions annotation provides the same options as the cucumber JVM command line. for example, we can specify the path to feature files, the path to step definitions if we want to run the execution in dry mode or not, etc.
Basically, @CucumberOptions enables us to do all the things that we could have done if we have used the cucumber command line. This is very helpful and of utmost importance, if we are using IDE such eclipse only to execute our project.
How to use it: Create one empty class with the @RunWith(Cucumber.class) annotation. The options to be used are defined with the @CucumberOptions.
Executing this class as any JUnit test class will run all features found on the classpath in the same package as this class. Name of the class could be anything and most common name for this class is RunCukeTest.java
Note: @Cucumber.Options is deprecated from version 1.1.5
lets look at the sample code for the RunCukeTest.java structure:
package com.sample;import org.junit.runner.RunWith;import cucumber.api.CucumberOptions;import cucumber.api.junit.Cucumber;@RunWith(Cucumber.class)@CucumberOptions(//your cucumber options goes here})public class RunCukeTest {// This class will be empty}Different options:
Element | Purpose | Default |
dryRun | true (Skip execution of glue code) | FALSE |
strict | true (will fail execution if there are undefined or pending steps) | FALSE |
features | the paths to the feature(s) | {} |
glue | where to look for glue code (stepdefs and hooks) | {} |
tags | what tags in the features should be executed | {} |
monochrome | whether or not to use monochrome output | FALSE |
format |
what formatter(s) to use - "pretty", "html:target/cucumber", "json:target_json/cucumber.
| {} |
Here is the code snippet which shows hows to write these options in code format
Although the table and code above summaries things very clearly but still let's look at each option one by one to understand it better.
package com.sample;import org.junit.runner.RunWith;import cucumber.api.CucumberOptions;import cucumber.api.junit.Cucumber;@RunWith(Cucumber.class)@CucumberOptions(dryRun = false,strict = true,features = "src/test/features/com/sample"glue = "com.sample",tags = { "~@wip", "@executeThis" },monochrome = true,format = {"pretty","html:target/cucumber","json:target_json/cucumber."junit:taget_junit/cucumber.})public class RunCukeTest {}Although the table and code above summaries things very clearly but still let's look at each option one by one to understand it better.
· dryRun: if dryRun option is set to true then cucumber only checks if all the steps have their corresponding step definitions defined or not. The code mentioned in the Step definitions is not executed. This is used just to validate if we have defined a step definition for each step or not.
· Strict: if the strict option is set to false then at execution time if cucumber encounters any undefined/pending steps then cucumber does not fail the execution and undefined steps are skipped and BUILD is SUCCESSFUL. This is what the Console output looks like:
and if Strict option is set to true then at execution time if cucumber encounters any undefined/pending steps then cucumber does fails the execution and undefined steps are marked as fail and BUILD is FAILURE. This is what the Console output looks like:
· Monochrome: if the monochrome option is set to False, then the console output is not as readable as it should be. maybe the output images will make this more clear.
Output When the monochrome option is set to false is shown in the below screenshot.
Output When monochrome option is set to true is shown in below screenshot.
· Features: features option is to specify the path to feature files. when cucumber starts execution, Cucumber looks for .feature files at the path/folder mentioned in features option. Whichever files are with .feature extension ( if there are no compilation errors) at the path/folder mentioned in features, are executed. below snapshot will make it clear on what path to define keeping in mind the project structure:
· Glue: glue option is to specify where the step definitions and glue code is present. Whenever cucumber encounters a step, the cucumber looks for a step definition inside all the files present in the folder mentioned in GLUE option. This also holds true for Hooks. below snapshot will make it clear on what path to define keeping in mind the project structure:
· Tags: what tags in the features should be executed or for that matter what tags should not be executed. for example: as per our example, whichever feature file or scenario would be tagged with @execueThis would be executed and whichever is tagged with @wip would not be executed. because of the "~" mentioned before @wip Tag. "~" in front of any Tag tells cucumber to skip scenario/feature tagged with that Tag.
· Format: format option is used to specify different formatting options for the output reports. Various options that can be used as for-matters are:
· Pretty: Prints the gherkin source with additional colours and stack traces for errors. use below code snippet for pretty:
format = { "pretty"}
· HTML: This will generate a HTML report at the location mentioned in the for-matter itself. use below code snippet:
format = { "html:target/cucumber"}
· below snapshot displays the kind of report that we will see.
· JSON: This report contains all the information from the gherkin source in JSON Format. This report is meant to be post-processed into another visual format by 3rd party tools such as Cucumber Jenkins. use the below code snippet:
format = {"json:target_json/cucumber.}
· below snapshot shows the kind of report we are going to see:
· Junit: This report generates XML files just like Apache Ant’s junitreport task. This XML format is understood by most Continuous Integration servers, who will use it to generate visual reports. use the below code snippet:
format = { "junit:taget_junit/cucumber.
below snapshot shows the kind of report we are going to see:
Well this summaries the content that i had for @CucumberOptions, and i hope that after reading this blog you have enough idea of @CucumberOptions and can utilize this powerful tool in your projects.
Q1) For what all languages Cucumber implementation is available?
Ans) Cucumber implementation is available for following languages:
• Ruby/JRuby
• JRuby (using Cucumber-JVM)
• Java
• Groovy
• JavaScript
• JavaScript (using Cucumber-JVM and Rhino)
• Clojure
• Gosu
• Lua
• .NET (using SpecFlow)
• PHP (using Behat)
• Jython
• C++
• Tcl
• Q2) Can we tag one scenario with two different tags?
• Ans) Yes
In Gherkin, each line that isn't blank has start with a Gherkin keyword, followed by any text you like. The main keywords are:
- Feature
- Scenario
- Given, When, Then (Steps)
- Background
- Scenario Outline
- Examples
There are a few extra keywords as well:
- """ (Doc Strings)
- | (Data Tables)
- @ (Tags)
- # (Comments)
Comments
Post a Comment