GOLANG & API TESTING WITH GODOG (Part 2)
The first part of this blog post was about the advantages of Cucumber. This second part is about ‘API Testing’ and ‘Godog’: The BDD framework for the Go programming language.
Keeping the Cucumber features that I mentioned in the first blog in mind, let’s explore Godog.
Steps for Testing with Godog are as follows:
- Installing Godog
- Writing test scenario in the feature file
- Implementing tests
Now, let’s review each one of these steps in more detail.
Installing Godog:
Like many libraries in Go, you can install it with go get command:
go get github.com/cucumber/godog/cmd/godog@v0.12.0
If go get command doesn’t work you can try with go install command.
You can also follow the steps in the Readme file of Godog which is very easy to work with.
Specifying test scenario in the feature file:
I will be using the reqres API as an example.
You may notice that we used the Background keyword in the feature file. Background is much like a regular scenario in which we can write some steps into. But it runs before all scenarios in that feature file. So, setting configuration by using the Background keyword will save us time and will prevent repetition.
Now, let’s run the feature file.
To run the feature file, we need the godog command:
godog reqres.feature
This command will run all scenarios in that feature file.
If you need to run some of the scenarios, you can use tags. Tags will help the feature file to be organized in a more effective way.
To run your tagged scenario:
godog . -t=@regression
When you use godog . with tag, it will run all the scenarios which have that tag in that directory.
After running the feature file, we get missing functions for unimplemented steps:
When we execute the godog command, GODOG will read the steps from the feature file and look for the code for this particular step. It will continue to generate these functions until we paste them into a go file.
Since we have test functions to implement, we can create a go file, paste these generated functions and start implementing them.
In GO, if you want to create a test file, your file name should end with _test.go. And this file should be created in the main directory.
The generated functions return pending error by default:
Implementing Tests
There are mainly four steps in API testing:
- Set the URL
- Set the expected data
- Send the request
- Assertion
There are a couple of different ways to follow these four steps with Golang.
In this project, I preferred using JSON files for setting the expected data. Golang offers many effective ways to deal with JSON files. After some comparison, I decided to use Tidwall’s gjson library.
GJSON is a GO package that helps retrieve data in a very easy and quick way from JSON. Especially its methods for single line retrieval is a lifesaver when you have big JSON data.
For installing GJSON, again we need to use the go get command :
go get -u github.com/tidwall/gjson
Leveraging the encoding/JSON standard library package is also an option for manipulating JSON files but if you want to get some part of data without creating a struct or map, I strongly advise you to use the GJSON library. The Get method in this library requires two parameters; JSON data (as a string) and the JSON field path. So, I created some helper functions to convert JSON to string:
Now, we can easily feed our test script from the feature file by providing these required arguments for the Get method.
Let’s go back to the four steps in API testing.
- Set the URL
Since we imported GJSON into our project, working with JSON files will be very simple and fast. So, we can choose our configuration file as a JSON file and set the URL in this file:
Now, we can set the URL by reading it from the configuration file.
Note that our function name is the exact sentence that we have written in the feature file.
Since we have the URL now, we can start playing with HTTP requests. However, we need to set the expected data before sending the request.
2. Set the expected data
As we already have a JSON reader in our project, let’s set the expected data in JSON files. This also makes sense in terms of the readability of JSON. At the end of the day, in API testing, we will always deal with JSON data and when we use JSON files, there is going to be compatibility. Also, in case there is an update in JSON, it is going to be much easier to update data in this file.
3. Send the request
We set the URL and expected data, so we are ready for sending the request. For sending the request and getting the response, I found the Resty library is very powerful. If you’re familiar with Rest Assured Library, you will like it, too.
Since this is a POST request, we need to set a JSON body. We already created a JSON file for the request body. The only thing we need to do is read that file. Let’s use our helper method that reads JSON files and returns JSON as a string. And if we parametrize file path from feature file, it means our test script will not include any hard code and we can use this POST method again by changing the file path in the feature file.
With the help of Resty, we will send a request and get the response.
Don’t forget to capture the status code and response body. Here, we created statusCode, requestBody, and responseBody variables as global values so that we can easily use them in other functions. Now we can start assertions which is the goal of all this effort.
In API testing, the first thing that we need to verify is the status code:
For assertions, I prefer to use Gomega which is a very powerful library. I created assert functions in the utility package so that I can use them in the entire project. Gomega is not the topic of this post, so let’s skip this for now and focus on how we pull the data from the data table.
In this function, to get the expected data, again we use the GET method from gjson. The first argument, requestBody is set in the previous function. First, we used the JSON helper to convert it to string and used it as the body in POST request, now we are using it to retrieve expected data. Then, by using a loop, we pass the JSON fields from the feature file. By writing this path in the Data Table, it is very easy to add new fields and increase our test coverage. With only this scenario, you can send many different POST requests by changing the JSON file path and JSON fields.
And this is the output of our automation tests:
To sum up, I explained how we use Godog with API tests:
- Write the scenario in the feature file by using Gherkin language.
- Run the feature file
- Copy and paste the auto-generated functions in _test.go file
- Implement the code
And for API testing we followed four steps:
- Set the URL
- Set the expected data
- Send the request
- Assertion
Happy Testing! :)
