Sharing state between steps in Cucumber-JVM using Guice

Filed under: Cucumber, Guice, — Tags: Behaviour-Driven Development, Gherkin, Share state between steps, cucumber-guice — Thomas Sundberg — 2017-08-16

A scenario in Gherkin is created by steps. Each step depends on previous steps. This means that we must be able to share state between steps.

The glue between Gherkin and the system under test is implemented as regular Java methods and implemented in regular Java classes. The steps are global in the sense that every step in the same package or subpackage relative to the runner will be found and executed. This allows us to define one step in one class and another step in another class.

Dividing steps between many classes may be a good idea. It is, however, probably not needed early in a project. The first reasonable division should therefore probably be no division. When you write your first scenario, you will most likely only have a few steps. Not more than that they can fit into one class without too much hassle. The first class with steps is probably small and you can easily find your way around in it.

The problem with too large step classes doesn't occur until after a while. You have added a bunch of scenarios to your project and finding your way around in the step definition class is getting harder and harder. The problem with large classes are that they

You would like to split the steps into multiple classes. The question is how.

(more...)

Use the same language

Filed under: Cucumber, — Tags: Agile testing pyramid, Behaviour-Driven Development, Polyglot, Testing iceberg — Thomas Sundberg — 2017-07-25

When implementing verification of an application using Cucumber, you have a choice of the language to use. Being able to choose is a good thing. But it also forces you to take a decision.

Cucumber is implemented in lots of different languages. The Cucumber site lists these implementations:

That's a lot of options! What should you use? The consultant answer is: "It depends".

(more...)

Sharing state between steps in Cucumber-JVM using Spring

Filed under: Cucumber, Spring, — Tags: Behaviour-Driven Development, Gherkin, Share state between steps, cucumber-spring — Thomas Sundberg — 2017-06-24

A scenario in Gherkin is created by steps. Each step depends on previous steps. This means that we must be able to share state between steps.

The glue between Gherkin and the system under test are implemented as regular Java methods and implemented in regular Java classes. The steps are global in the sense that every step in the same package or subpackage relative to the runner will be found and executed. This allows us to define one step in one class and another step in another class.

Dividing steps between many classes may be a good idea. It is, however, probably not needed early in a project. The first reasonable division should therefore probably be no division. When you write your first scenario, you will most likely only have a few steps. Not more than that they can fit into one class without too much hassle. The first class with steps is probably small and you can easily find your way around in it.

The problem with too large step classes doesn't occur until after a while. You have added a bunch of scenarios to your project and finding your way around in the step definition class is getting harder and harder. The problem with large classes are that they

You would like to split the steps into multiple classes. The question is how.

(more...)

Gherkin scenarios - some good properties

Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin, Scenarios — Thomas Sundberg — 2017-05-29

Are there any global properties that a Gherkin scenario should fulfill? A short answer is, no.

A longer answer is that there are some properties that are good and probably useful in many different contexts.

(more...)

Organising scenarios and steps in Cucumber

Filed under: BDD, Cucumber, — Tags: Behaviour-Driven Development, Gherkin, Java — Thomas Sundberg — 2017-04-28

Writing a few scenarios in a feature file is easy. After while, when you have a lot of scenarios, you may want to divide them. How should you split them in such a way that finding a specific scenario is easy?

In the beginning it is easy to write the glue code needed to connect your scenarios with the system under test. But after a while it gets messy. You have a lot of methods and finding the one you need gets harder and harder. You need to start organising the steps in a good way to be able to find them without to much hassle.

These divisions can be done in a number of different ways. Some may support your development and maintenance. Other may hinder you. Is there an optimal division?

(more...)

Sharing state between steps in Cucumber-JVM using PicoContainer

Filed under: Cucumber, PicoContainer, — Tags: Behaviour-Driven Development, Gherkin, Share state between steps, cucumber-picocontainer — Thomas Sundberg — 2017-04-01

A scenario in Gherkin is created by steps. Each step depends on previous steps. This means that we must be able to share state between steps.

The glue between Gherkin and the system under test are implemented as regular Java methods and implemented in regular Java classes. The steps are global in the sense that every step in the same package or subpackage relative to the runner will be found and executed. This allows us to define one step in one class and another step in another class.

Dividing steps between many classes may be a good idea. It is, however, probably not needed early in a project. The first reasonable division should therefore probably be no division. When you write your first scenario, you will most likely only have a few steps. Not more than that they can fit into one class without too much hassle. The first class with steps is probably small and you can easily find your way around in it.

The problem with too large step classes doesn't occur until after a while. You have added a bunch of scenarios to your project and finding your way around in the step definition class is getting harder and harder. The problem with large classes are that they

You would like to split the steps into multiple classes. The question is how.

(more...)

How do you create a good specification?

Filed under: BDD, Cucumber, Executable specification, Requirements, — Tags: Behaviour-Driven Development, Gherkin, Good specifications — Thomas Sundberg — 2017-02-26

A good specification is

An interesting question is "How do you create a good specification?" There are obviously a lot of different ways to end up with a good specification. You may be lucky and randomly end up with something good. There are, however, better ways than to rely on luck.

(more...)

What is the difference between a specification and a good specification?

Filed under: BDD, Cucumber, Executable specification, Requirements, — Tags: Behaviour-Driven Development, Gherkin, Good specifications — Thomas Sundberg — 2017-01-30

What makes one specification a bad specification and another specification a good specification? What is the fundamental difference between two specifications?

(more...)

Cucumber and Gherkin are not about flexibility

Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2016-12-04

Sometimes I see questions asking for flexibility in Gherkin, the language used by Cucumber. The purpose is often to remove duplication. An example may be this Stackoverflow question

Removing duplication is often a very a good thing. It is, however, sometimes better to keep duplication and gain clarity and readability.

(more...)

The Right Tool for the Job

Filed under: BDD, Cucumber, Test automation, — Tags: Behaviour-Driven Development, Testing iceberg — Thomas Sundberg — 2016-07-25

No tool is perfect for all jobs. When you start out automating Behvaiour-Driven Development, BDD, using Cucumber you tend to use it for much more than you need. This will work, but it is not a good idea for a few reasons:

(more...)

Cucumber Anti-Patterns

Filed under: BDD, Cucumber, — Tags: anti-pattern — Thomas Sundberg — 2016-06-22

This a transcript and interpretation of a podcast where Aslak Hellesøy, Matt Wynne, and Steve Tooke from Cucumber Ltd have a chat about the BDD tool Cucumber and anti-patterns they have come across.

I have changed the order of the patterns described, rephrased some parts, and added a few of my own thoughts. The original podcast is available at https://cucumber.io/blog/2016/05/09/cucumber-antipatterns.
It is worth your time to listen to it.

(more...)

Cucumber regular expression cheat sheet

Filed under: Cucumber, — Tags: Cucumber-JVM, Regular expression — Thomas Sundberg — 2016-04-02

If you are like me, then you will feel a lump in your stomach when you realize that you need a regular expression. I think that the saying "If you have a problem that requires a regular expression, then you have two problems" is very appropriate most of the time.

It turns out that you need a some regular expressions when you are working with Cucumber. In this case, they are usually not very complicated.

(more...)

Where should you use Behaviour Driven Development, BDD?

Filed under: BDD, Cucumber, — Tags: Agile testing pyramid, Common understanding, Test automation, Ubiquitous Language — Thomas Sundberg — 2016-03-26

When I was at the European Testing Conference 2016 in Bucharest, a colleague asked me about my thoughts on how they should use Behaviour Driven Development, BDD. I didn't get a good chance to elaborate on my view so I decided that I should write this instead.

(more...)

Gradle and Cucumber-JVM

Filed under: Cucumber, Gradle, Programming, — Tags: Cucumber-JVM, JUnit, Java — Thomas Sundberg — 2015-12-26

Gradle is a great build tool. Cucumber-JVM is a great tool for executing Gherkin. They don't really work well together. At least not out of the box. Gradle defaults to hide the output on stdout and stderr. This is very unfortunate since this means that the code snippets Cucumber-JVM suggests when there is a missing step are hidden.

Let me show you an example on how to setup a Gradle project so it can execute Cucumber-JVM and give you the snippets you want as starting points for your steps.

(more...)

BDD with Cucumber-JVM at GeeCON TDD 2015

Filed under: BDD, Cucumber, Java, — Tags: Behaviour driven development, Cucumber-jvm, GeeCON — Thomas Sundberg — 2015-01-30

This blog post is the same as the example I presented at GeeCON TDD in Poznan, Poland, January 2015. It is a step-by-step example that I hope you will be able to follow and implement yourself.

But before I begin with the implementation, let me reason about why you should care about BDD.

Behaviour Driven Development, BDD, is a way to try to bridge the gap between developers, who can read code, and people who are less fluent in reading code. Cucumber is not a tool only for acceptance testing. It is a communication tool where you can express examples in plain text that anyone can read. These examples can also be executed. They are the outcome from discussions between stakeholders, developers and testers.

Given this, the technical part of BDD that I will show you is the less important part. The most important part is the conversations that occurs and defines the application that should be implemented.

(more...)

An email marketing system built using test first and Cucumber-JVM

Filed under: Cucumber, Java, — Tags: BDD, Cucumber-jvm, Executable specification, JDD 2014, Java Developer Day 2014, Living documentation, Test automation — Thomas Sundberg — 2014-10-23

This is the example I implemented at JDD 2014 in Krakow, Poland at my Cucumber-JVM tutorial.

It is a (baby) step by step tutorial. The purpose for me taking baby steps is that you should be able to follow and implement the same things. Be prepared to spend some time with the implementation, it will probably take you a few hours.

Before we dive into the example, let me define what I am aiming for. My goal is to show you how an example (or specification if you want) can be executed. The example is written in plain text and is used to automate the testing of the system I will create. These executable examples can later be relied upon for regression testing and a living documentation.

(more...)

Cucumber-JVM Hello world with Gradle

Filed under: Cucumber, Gradle, Maven, — Tags: Automation, Cucumber-jvm — Thomas Sundberg — 2014-08-24

Cucumber is very easy to run from Maven. How do you run it from Gradle?

The answer to this question is: It is as easy as to run it from Maven. Depending on your background, perhaps even easier. The reason for this is because we run Cucumber from a JUnit runner. That is as a unit test with a specific runner. Maven or Gradle really doesn't have anything to do with this. It all boils down to the need for a Gradle project that can build a Java project. A Java project that has a unit test.

(more...)

Cucumber data tables

Filed under: Cucumber, Programming, — Tags: BDD, Behaviour Driven Development - BDD, Cucumber, Cucumber DataTable, Cucumber-jvm, DataTable, JUnit, Java, Maven, Test automation — Thomas Sundberg — 2014-06-30

Cucumber has a nice feature that will help you to use tables in your scenarios. The table can easily be converted to a list or a map that you can use in your step. I will show you a few examples that may help you get started.

(more...)

Cucumber-JVM Hello world

Filed under: Cucumber, Requirements, Software development, Test automation, — Tags: BDD, Behaviour Driven Development, Behaviour Driven Development - BDD, Cucumber, Cucumber-jvm, Executable specifications, I T.A.K.E. Unconference 2014, Java, Living documentation, Maven, Test automation — Thomas Sundberg — 2014-05-29

This is the example I showed at the I T.A.K.E. Unconference 2014 in Bucharest. I created it for your convenience so you should be able to implement it yourself after the presentation.

Before we dive into the example, let me just recap what I am aiming for. I will show you how an example (or specification if you want) can be executed. The example is written in plain text and it is used as the basis for an execution. This example can later be relied upon for regression testing as well as living documentation.

(more...)

Why Cucumber?

Filed under: Cucumber, Executable specification, Test automation, — Tags: Automated acceptance criteria, Automated acceptance tests, Collaboration, Concrete examples, Cucumber-jvm, JUnit, Readability, Requirements — Thomas Sundberg — 2014-03-30

Before I can try to motivate why you should use a tool, let me define what it is and what it does.

What is cucumber?

Cucumber is a tool for collaboration and testing. It is used to create examples of behaviour that are executable. Creating examples in a collaborative way emphasize close cooperation between business analysts, testers and developers. The examples they come up with can be used as acceptance tests for the system being developed. It can be used as a testing tool where the tests are defined in a business friendly language while still being executable.

Goal

Our goal is to create a common understanding of the problem and therefore simplify the communication between all parties involved. We would also like to get something that is possible to use for automating the verification of the resulting program. That is, use as a base for test automation of the system.

(more...)

Cucumber-JVM - not just for testing GUIs

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Cucumber is a tool that supports Behaviour Driven Development, BDD. A lot of people think that the only place where a system has behaviour is in the user interface and especially in the graphical user interface. As a developer I know that this is not the case. All systems have behaviour at different places and different levels.

I will show an example of how a system can be developed using its desired behaviour and start from a non graphical point. I will work from the model down to the database and when I'm happy with the logical behaviour I will add a graphical user interface on top of it. I will actually add a few different interfaces; two web-based, one swing and two different types of web services. The result will be an example of Model View Controller, MVC, developed using BDD.

An important point when I add the GUIs or web services is that I will not change the desired behaviour. I will only change how the behaviour is verified. This is one way of showing you that Cucumber and BDD is not about testing GUIs. It is about systems behaviour.

(more...)

Building the model

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - Introduction

The feature I will start with looks like this:

src/test/resources/se/waymark/rentit/Rent.feature

Feature: Rental cars should be possible to rent to gain revenue to the rental company.

  As an owner of a car rental company
  I want to make cars available for renting
  So I can make money

  Scenario: Find and rent a car
    Given there are 18 cars available for rental
    When I rent one
    Then there will only be 17 cars available for rental

It consists of three parts:

(more...)

A JSF web application

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - Building the model

Many modern applications are built as web applications. The benefits are obvious, you don't need to package your software in shrink-wrap and send it to your customers. Upgrading is easy, you have to upgrade the server you host the system on and that's it.

The first user interface I will add to the rental system will therefore be a web GUI. It will be the simplest possible solution and the goal is not to build a fancy web app. The goal is to show how Cucumber can control a tool like Selenium WebDriver to assert the behaviour of the web application.

(more...)

A Wicket web application

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - A JSF web application

A wicket application is yet another web application. I divide the project in two parts as earlier. The only large difference is the support class that will connect to the system under test. It has been adapted for another web application.

(more...)

Building a Swing GUI

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - A Wicket web application

A Java Swing application is yet another graphical user interface that can be attached on top of the model developed earlier. The project is divided in the same way as earlier, in two parts. The only large difference here is the support class. It need to be adapted for a Swing user interface. Another difference is of obviously that the GUI is developed using Swing. But that has actually a rather small impact on the verification.

(more...)

A RESTFul Web Service

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - A Swing application

A RESTFul web service is yet another way to use the model. It doesn't have any user interface and it is expected to be used by third party suppliers. I divide the project using two Maven modules as earlier. One for the production code and one for the verification. The only large difference here is the support class that will connect to the system under test but now has to be adapted for a RESTFul web service instead of any graphical interface. Another difference is of course that there is no GUI and that it is developed using a Jersey servlet instead, but that has little impact on the verification.

(more...)

A SOAP Web Service

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - A RESTFul web service

A SOAP Web Service is yet another way to use the model. It doesn't have any user interface and is expected to be used by third party suppliers. I divide the project using two Maven modules as earlier. One for the production code and one for the verification. The only large difference here is the support class that will connect to the system under test but now has to be adapted for a SOAP web service instead of any graphical interface or RESTFul web service. Another difference is of course that there is no GUI and that it is developed using a CXF instead, but that has little impact on the verification.

(more...)

Conclusion

Filed under: BDD, Cucumber, Test automation, — Tags: CXF, Cucumber-jvm, JSF, JUnit, Jersey, MVC, Model view controller, REST, RESTAssured, RESTFul, Selenium, Soap, Swing,, Swinggui, WebDriver, Wicket — Thomas Sundberg — 2012-11-01

Previous - A SOAP web service

I have shown you five different ways to implement something on top of a common model using the same behaviour. I hope you can agree that it is obvious that BDD and Cucumber-JVM is not just meant for testing GUIs. It can be used to assert any behaviour.

(more...)

Test drive an implementation using an Executable Specification - revisited

Filed under: Cucumber, Java, Test automation, — Tags: Acceptance test, Acceptance test driven development, Agile Cambridge 2012, Cucumber-jvm, Specifications by example — Thomas Sundberg — 2012-09-28

An example is perhaps the best way to describe something. Concrete examples are easier to understand than abstract descriptions.

I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.

(more...)

Testing a Web Service with SoapUI, JUnit, Maven and Cucumber

Filed under: Cucumber, Maven, Test automation, — Tags: BDD, Behaviour Driven Development, Behaviour Driven Development - BDD, Cucumber, Cucumber-jvm, Executable specifications, Java, POJO, Readability, SoapUI, Test web services, soap — Thomas Sundberg — 2011-11-16

An example is perhaps the best way to describe something. Concrete examples are easier to understand than abstract descriptions.

I will show how SoapUI can be used to test a web service. I will also show three different tools that can be used to control SoapUI. This tool chain can easily be made a part of your continuous build.

(more...)

Why separate test definitions from a driving JUnit class?

Filed under: Cucumber, — Tags: Cucumber-jvm, JUnit, Java — Thomas Sundberg — 2011-10-31

Why should the step definitions be separated from the driving JUnit class when using Cucumber for Java?

(more...)

Testing a web application with Selenium 2

Filed under: Automation, Cucumber, Maven, Selenium, Software development, Test automation, — Tags: BDD, Behaviour Driven Development, Behaviour Driven Development - BDD, Cucumber, Cucumber-jvm, Executable specifications, Java, Page Object, Parameterized JUnit, WebDriver — Thomas Sundberg — 2011-10-18

Selenium a great tool for testing web applications. The current version, Selenium 2, is a merge between Selenium and WebDriver. I will walk you through an example where we test a web site using Selenium in a few different ways. This is the same example as I demonstrated at Scandev on tour in Stockholm 18 October 2011.

(more...)

Test drive an implementation using an Executable Specification

Filed under: Cucumber, Java, Programming, — Tags: #abe2011, Acceptance test driven development, Agile by Example 2011, Agile by Example 2011, Cucumber-jvm, Executable specifications, Executable specs, Specifications by example, Test automation, Test driven development — Thomas Sundberg — 2011-09-16

An example is perhaps the best way to describe something. Concrete examples are easier to understand then abstract descriptions.

I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.

(more...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS