Think Code AB Blog Thoughts and opinions from Think Code AB Data tables in Cucumber 3

Version 3 of Cucumber for Java has recently been released. It brings Cucumber expressions to Cucumber-JVM. It also brings a new implementation of Data tables.

From a Gherkin perspective, nothing has changed. Data tables are supported as earlier. As a developer you need to adapt the steps a bit.

I T.A.K.E. Unconference 2018

In june 2018 I will return to I T.A.K.E. Unconference in Bucharest, Romania. I run two sessions there:

These two sessions combine something I think is very important. They combine clean and understandable code with discovering what to implement. Understanding what to do is often more valuable than to know how to implement something. Implementing the wrong solution may even be harmful and is just as much waste as implementing something wrong.

What does BDD really stand for?

BDD is the acronym for Behaviour-Driven Development. It is a way to describe the behaviour of a system and a way to make sure that it is developed to behave as it should.

BDD is used for understanding what to create and for verifying the result.

Business-Driven Development

But BDD could also be the acronym for Business-Driven Development. BDDers work really hard to bridge the communication gap between development and business. We really try to involve the business people in the development. We value their input and love discussing concrete examples describing what the system should do. How it is done is less important when understanding what really matters for the business. Focusing on the what and not the how is a differentiator between communicative developers and regular developers.

Testing stage 2018

In April I will be talking at Testing stage in Kiev, Ukraine

I have two sessions:

  • Test automation - the supporting architecture
  • Why is good design important for test automation?

They are connected in the sense that they are both about how to implement the support code you need for your test automation initiative. As a developer, I know that how you implement code is really important. It is ultimately a matter of maintainability. And maintainability is probably the most important property a piece of code can have after being correct. Code that can't be maintained will create problems for you during the entire lifetime of your product.

Getting started with Cucumber for JavaScript

I usually describe myself as a Java backend developer. That is actually not completely true. I tend not to shy away from the frontend, but I prefer the backend because it is usually much easier to test.

This backend focus has allowed me to almost entirely miss out on JavaScript development. I can't say that I mind that much. I use JavaScript when a web page needs it, but I use Google a lot to find examples I can modify to fit my needs.

One thing I am curious about though is to be able to use Cucumber-js. I have never done it before so this a blog post that will describe my experience getting started.

Languages supported by Cucumber-JVM

Cucumber-JVM supports a lot of languages for writing concrete examples that describes a wanted behaviour. The examples are written in feature files. The five important keywords are:

  • Given
  • When
  • Then
  • And
  • But

These keywords are translated into many different languages. So many that it may be hard to keep track of them. How do you find the keywords for your native language? Luckily, cucumber can help with that using its built in help system.

Finding the Unknown Unknown

What is the unknown unknown?

The unknown unknown are the things, sometimes problems, of the task we are trying to achieve that no one has thought of. It is on the level that nobody is even aware about them, therefore the name unknown unknown. We don’t even know that we have a problem in this area. This is where the nasty bugs live and thrive in a software system.

Cucumber - tagging scenarios

When you do Behaviour-Driven Development, BDD, you start with a conversation. The conversation leads to concrete examples that can be used as acceptance tests. When you implement the acceptance tests, it may be the case that you can finish the development shortly after. Unfortunately, it may also be the case that the development will take some time. Maybe even a few days.

How do you handle the case where you commit your changes to your version control system and your continuous integration server build the system but the acceptance tests doesn't pass just yet?

There are a few different solutions you can use:

  • Do not commit the new acceptance test
  • Keep the current work in a separate branch that isn't built
  • You comment out the example
  • You tag your example in such a way that it will not be executed
Test automation and Selenium: 4 rules for keeping your tests simple

To support ever shorter release cycles you need to automate testing, and to do that, you need to use a program that can verify your desired behavior. One option is to use tools that can record and replay a scenario, but those are a nightmare to maintain, and you'll probably end up writing the code needed for automating the tests yourself.

For automating the testing of a web application, Selenium is a better way. It takes some programming skills, however, and you must take care to ensure that your tests are easy to understand and maintainable.

Writing maintainable, easy to understand tests might seem hard, but not if you follow these four, simple rules of design.

Sharing state between steps in Cucumber-JVM using Guice

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

  • are not coherent, they are about a lot of different things at the same time
  • don't follow the single responsibility principle, there are probably many reasons why a class has to be changed
  • are messy, it is hard to find what you need

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