My first jabs at BDD development with Spring boot, Spock and Geb

Hello Guys,

In this tutorial, we are going to take a look at how to use tools and frameworks available to us today in order to tackle the BDD approach of development. We will not go into the idiomatic side of what is BDD and why it’s the buzz word today. There are lots of write ups out there that would enlighten you more that what I would ever say here.

Without further delays, let’s get to our business. I am going to take a little ambitious project like building a small blog application. We are going to enumerate the features of our blog application and write their specs in Gherkin “like” syntax and write our test for it.

Because this tutorial can be long I would rather split it unto mini series:

  • Overview and project setup
  • Unit Testing Home Controller
  • Testing the Login aspect
  • Testing the application usage itself
  • Testing the controllers
  • Testing the API

Overview and project setup

We are going to build the authentication part of our application . We will use the following

Since we are doing a BDD approach, let’s define our stories. What we want to achieve and that it means when we say our tests have passed. In this first series, we will want to be able to register and login.

In typical BDD world the narrative for what we want to achieve is like below:

So for registration and login features, it will be like:

Now that we know what we want in this first post, we will have to define its acceptance criteria, which is what I was referring to as a Gherkin like syntax.The structure of the acceptance criteria is displayed below. One Acceptance criteria can have multiple scenarios.

Our Scenarios are defined below:

I have maybe over used the And construct but it was intentional to show how well structured this can be. It can totally be done with fewer And construct. Below I will be discuss the Scenario 2 with fewer And. Scenario 1 is typically what we call the happy path of the test and throughout my pains as a developer that’s the only thing that we seem to be concerned about. We usually forget the sad paths of the test and some times when in production , this comes back to bite us.

Kindly note that we can have as many sad path as we want. One example would be to have one scenario for each missed field ie. one for : name, username, and password etc.

Project Setup

Now that we know what is required of us as developers of the blog application and especially what validates our deliverable as “done”, we can launch our favorite IDE and start writing our acceptance criteria first. I will be using Intellij Ultimate for this project and Gradle instead of Maven.

Creating the project

Defining project namespace , sdk build tools etc

Choosing Web Component of our spring boot app

Choosing Thymeleaf templating system of our Spring boot app

Choosing DB layers of our Spring boot app

Final Gradle level tweak for our Spring boot app

Structure of our Spring boot app at its creation

Our project build.gradle should also look like below:

I have stumbled upon a nice way of separating unit testing from integration testing on PETRI KAINULAINEN’s blog and I thought it’s cool so I borrowed some of the technics discussed there to put our Automated user acceptance or our Automated functional tests into a separate folder.

The plugin used by Petri is available in Bintray jcenter let’s make some few changes to our build.gradle file so we can download from jcenter.

I have auto import enabled so this will immediately take effect but for those who needs to be really sure , we can build the project so all dependencies get downloaded.

Locate gradle window and the build subfolder

When you build you will have a similar output

After building it, we can now add our plugin. Make sure your build.gradle file looks like below:

You will also need to apply the plugin with the following syntax apply plugin: ‘org.unbroken-dome.test-sets’:

We are now going to add most of our testing stack from this point. There are more to be done with the configuration of the org.unbroken-dome.test-sets but since it’s going to create a separate folder for our testing we might as well have everything before that so it factors that in its folder creations.

Let’s add Spock and the Groovy squad 😀 . Spock is written with groovy so we need to have groovy in our test scope.

As many might be aware, Geb is a browswer automation tool so it depends on WebDriver. Since I am using firefox for this post, you need to have a geckodriver installed on your machine for this to work. I installed mine using brew. Below shows spock and selenium dependencies added.

let’s add the rest of our Testsets configuration. Open your build.gradle file and add the following.

This creates the following groovy, java, resources folders for us. You might want to build the project again for this to work:

Our Integration Test folder and subfolders created

Let’s hook up some boostrap and jquery distin inside our project. Java community has a nice way of managing frontend dependencies just the same way as server side though. I have added the layout-dialect to the dependencies because we will be using the decorator feature of our templating system.

By now our full build.gradle file should look like the following

Before jumping straight to the writing of testing, let’s verify the sanity of our project. Let’s create a simple home page and test it to see if we have everything set out for the project. That will have to be in the next article.

Leave a Comment

Your email address will not be published. Required fields are marked *

captcha * Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.