In this chapter, let us setup a Java, Spring Boot project with Cucumber, create a simple feature file, implement the step definitions for the Given, When, Then steps in that feature file and run it. Just follow along the chapter and try doing all the steps. This will give some familiarity to Cucumber and Behavior Driven Development (BDD). We will learn the concepts as we go.
Feature files are specifications. A feature can be represented in different ways/patterns. Here, let us see different patterns for creating feature files, their pros and cons. You may learn all the patterns and use them accordingly.
In 'Different patterns for creating Cucumber Feature files' we learnt various ways/patters to represent feature or product specification. Here, we will continue the same but with more of a real world use case. Let us see 3 patterns to represent complex objects in feature files. Imagine we are creating a REST API. In order to test the API behavior, we need to call the API from step definition. If the payload for the API to test is expected as JSON, we need to convert the data in DataTable to a JSON so that it can be used as payload to call REST API from step definition. If we can convert DataTable to a Java Object, we can easily convert that to a JSON. Let us learn that here.
We learnt various patterns to represent features or product specifications. Here, let's apply 'Spreadsheet DataTable' pattern to test the API that is used to create a new employee in our HR Software. In this process, we will add few more maven dependencies to create and call the API. To be specific, we will use RestAssured library to call the REST API from the step definition methods.
We learnt how to use BDD and Cucumber to develop and test 'Create API'. Here, let's go a little deeper and learn how to represent validation use cases in feature file and test the same.
We use 'Given Step' to gather inputs, 'When Step' to call the API or perform the desired operation using the data gathered and 'Then Step' to assert the expected result/response. There are 3 different strategies to share data between step executions. First one is to store the state as StepDefinition class instance variables. We have been doing this in the past chapters. Second strategy is to use a class with @ScenarioScope annotation and the last one is to use a ThreadLocal object in a Singleton class. In this chapter, let us see how we can use the @ScenarioScope annotation and ThreadLocal to share state between step executions.
We are primarily dealing with REST APIs. In all our test, we need to assert the HTTP Response Code. Step Definition code to assert the HTTP Response Code can be used in multiple feature files. Hence, in this chapter, we will move that to a separate class called CommonStepDefinitions.java. In future if there is a need to share a step definitions across multiple feature files, we can add those methods to CommonStepDefinitions.java.
Calling REST APIs to create a resource, update a resource, get a resource, delete a resource require some boiler plate code. In our example, we are creating API for a HR Software. In order to test the API we need to call them from step definition classes. If we can move the code to call REST APIs to base class, every step definition class that needs to call REST API can leverage that instead of again and again writing code to call APIs. Here, let us see how and what can be moved to step definition base class.
In databases, we use auto increment columns for primary key. JPA/Hibernate uses the @Id annotation to deal with getting the next value when inserting the records in to the database. For testing, we should be able to set the identifier when we setup the data so that we can use the same identifier to perform some actions on the respective object. If you explicitly set the identifier before creating a resource, JPA/Hibernate checks if the record with the given id exists. If not exists, JPA/Hibernate ignores the supplier identifier and gets the next value from database. This behavior makes it hard to set up and use data for testing. Here, let us see how we can change the default behavior of JPA/Hibernate and make it use the identifier supplied and use auto generate only when no identifier is supplied.
We use boolean data type for certain fields in our code. There are 2 possible values for the boolean field in java, they are true and false. If we need to set value to a boolean field in feature file, we need to use true/false. But, from a Product Owner perspective, they wish to see the value as YES/NO instead of true/false. In this chapter, we will learn how to convert YES/NO in feature file to true/false. Also, we will learn how to use relative dates instead of fixed dates in test cases.
Previously, we learnt how to use BDD to implement and test 'Create API'. Here, let us learn how to create feature files for 'Update API'. In order to update something, it should exist. So before update, we have to setup the necessary data. To setup data, we will use 'Background' in feature file.
Previously, we learnt how to implement and test 'Create API', 'Update API'. Here, let us learn how to use BDD to implement and test 'GET APIs'. Also, let us see how we can compare the expected results with the actual results using AssertJ library.
Cucumber has various built-in plugins to generate reports. In this chapter, we will see how we can generate, package it and expose them as URLs along with the APIs. Report is a plugin in case of Cucumber. To enable any available report, you may need to set Cucumber plugin property in junit-platform.properties.
This tutorials walks through various best practices and design considerations while developing REST APIs.
If you have heard about Behavior Driven Development (BDD) and looking to learn how to do BDD using Java, Spring Boot and Cucumber, you are at the right place. This hands on guide will help you learn on how to setup Java Spring Boot project with Cucumber, different patterns for creating feature files, techniques to reuse + reduce step definitions code. It also teaches you on how to apply the patterns and techniques when creating feature files and step definitions to test various types of APIs all in a pragmatic way.