Categories: Uncategorized

by Jerome Josephraj


This tutorial explains, how you could roll out Behavior Driven Development and automate REST APIs in minutes without writing any code using NoCodeBDD. Before diving into the topic, let’s look at some of the basic concepts of REST and Behavior Driven Development. If you are familiar with REST and Behavior Driven Development, you can skip to Implementing BDD using NoCodeBDD section.

REST Basic Concepts

Representational State Transfer (REST)

REST is an architectural style. It provides standards between systems on the web, making it easier for systems to communicate with each other using HTTP.

In a REST application, you have a REST application that consumes the REST API and a client application that calls the REST API. When you roll out Behavior Driven Development, you will be calling a REST API as a client to test the behavior of the application that has implemented a REST API that consumes the message from a client and executes business logic based on the data that it receives and may provide a response to the client.

REST is primarily used over HTTP. In general following HTTP verbs are used to interact with a REST application:

  • GET
  • POST
  • PUT

Here is a nice and concise explanation in Stackoverflow explaining each of the above verbs.

When using POST, it worth noting that you can send data in 3 ways called as Form content types:

  • x-www-form-urlencoded – used to send simple key value pairs
  • form-data – used to send binary data e.g. files, images, etc…
  • raw – Large Ascii content such as JSON

When calling a REST API, you also need to pass few Header information by default other than the ones that the application expects. You also need to know the message that you need to send, if there is one when calling REST API.

Required Data to Test REST API

In order to call REST API using NoCodeBDD, all you need to know are following information:

  • HTTP Verb i.e. GET, POST, PUT, DELETE etc…
  • REST URL that you require to call/test
  • Message, if there is one, that is required by the consuming REST API
  • Form content type
  • Response status that is expected from the REST API
  • Response message, if there is one, that is expected from the REST API

The above information should be discussed and shared during the collaboration phase of Behavior Driven Development.

Behavior Driven Development

The most important aspect of Behavior Driven Development is that it reduces ambiguities in Software Requirements by encouraging collaboration between three amigos and writing requirements as real world examples. When rolling out Behavior Driven Development, the three amigos; QA, Dev and the Tester, analyse the user story together and derive scenarios and discuss details on how these scenarios should be implemented.

Typically, each User Story is created as a Feature and each Feature has multiple scenarios. These scenarios have multiple steps, which are written in a plain English using Gherkin language. Let’s look at an example of how you would define Feature, Scenario and Steps.

Example User Story

As a Customer, I want to be able to search for a book with an Author’s name. The search result should give me all books in Alphabetical order.

A typical Feature, Scenarios and Steps for the above Example would look like

Feature: Search for a book using Author’s name (User-Story-x)

For the sake of brevity, let’s look at one sample scenario.When you actually implement Behavior Driven Development, you will be deriving as many scenarios as you can in order to make sure all aspects of the requirements are discussed and covered in implementation and in testing.

Scenario: A total list of books should be returned in alphabetical order when the user searches for books using a valid Author name

Given Five books are available with author name “Agatha Christie”
When user searches using the Author “Agatha Christie”
Then the response should be valid
And the response message should contain five books in total

Once the Feature, Scenario and Steps are written, the next step is to automate the Scenarios. Typically in order to automate the steps, you are required for each of the steps. That is for the above Scenario, you need to define four methods mapping those steps. Since NoCodeBDD, is a scriptless Behavior Driven Developement Automation tool, you don’t require any code to automate. All you have to do is provide the few information and NoCodeBDD will take care of automation.

In this next section, we will look at how the above scenario can be automated using NoCodeBDD.

Automating Behavior Driven Development using NoCodeBDD

Using NoCodeBDD, it is extremely easy to automate the Features that you created as part of Behavior Driven Development. All you have to do is click on Step Definition menu, provide the required information that you collected in Required-Data-to-Test-REST-API section and run the Features. It will take only minutes to automate a scenario. Let’s look at this step by step of how this can be done using NoCodeBDD.

Step 1: Create Feature, Scenario and Steps

Following GIF shows how Features, Scenarios and Steps are added in NoCodeBDD

Step 2: Create Step Definitions

Once Steps are defined, all you have to do is, click Step Definition menu which is under the burger menu next to Step as shown in the GIF below

Step 3: Provide required details to call REST API

In the Step Definition page, select “New Step Definition”, then select REST, as we will be calling a REST API, select Send API Request, and in the “ADD API Request” dialog, enter the required details as shown in the GIF below

Step 4: Asserting REST API

To Assert a response from a REST API, all you have to do is, go to Step Definition page, then select REST and select “Assert API Response” and assert either the status received from a REST API or the message. This is shown in the GIF below

Step 5: Run the automated Steps

Once the required details are added, all you have to do is press Run menu and run the automated Feature or Scenario. After running the scenario, you can view the details of what data been sent including Header information in the Audit page. This is shown in the GIF below

Step 6: Reports

Once you have run a Feature or Scenario, if you want to refer to the results anytime in the future, you can go to Reports and view. This is shown in the GIF below

As you have seen Automating Behavior Driven Development is a piece of cake using NoCodeBDD. One of the pain points of rolling out Behavior Driven Development is the automation part as it takes quite a lot of time to implement, it requires a resource with coding skills and is difficult to maintain. NoCodeBDD removes all those pain points by generating the automation code.


Subscribe to our free newsletter.

Related Posts

View all

  • I had the pleasure of hosting a webinar with two industry experts, Rebecca Stone from IBM. During the webinar, Rebecca shared her experience in successfully implementing BDD in a large government project, highlighting the benefits of BDD, why and how she used OOPSI and its role in overcoming challenges faced […]

    Continue reading
  • Key Considerations for Rolling Out BDD in a Project Key Considerations for Rolling Out BDD in a Project

    Rolling out BDD in a project requires careful planning and a well-structured process. As a tech consultant on a large project, I had to make several changes to their BDD process and automation suite implementation. Some changes were straightforward, while others proved more challenging. If you’re considering implementing BDD in […]

    Continue reading
  • 10 Tips for Writing Effective BDD Scenarios When rolling out BDD having a clear and concise scenario writing is a vital aspect of successful BDD adoption. This blog post will provide you with 10 tips to enhance your BDD scenario writing, making it easy to understand, maintainable, and efficient. 1. […]

    Continue reading
  • It will be difficult to automate testing if you don’t consider it when creating your web application. It will be difficult, regardless of whether you are a code wizard or a no-code ninja. Here are some crucial ideas to have in mind as you develop your app to make testing a […]

    Continue reading