Hi, I’m Vladimir Pasiuga, and I work at NIX United as a quality assurance engineer.
I've been working in the IT field for the past 7 years. I worked as a manual tester for 2.5 years on a healthcare project that comprised UI and API components, and currently, I’m working on an automated testing project, where the application for the medical field consists only of an API.
I'll go over API testing in detail in this article, so this content will be helpful for QA beginners. You'll learn what an API is, what tools our team uses to test APIs manually, and what technologies we use for automated testing. I'll also talk about how I've used the Cucumber and Spock frameworks to automate API testing.
Let's Quickly Go Over the Tech
Before we get into the meat of API testing, let's brush up on some fundamental ideas. An API allows software components to exchange information with one another. To put it another way, the API acts as a link between internal and external software processes. If you imagine software as a black box, the API is a set of knobs that the user can twist, push, and pull as he pleases.
Today, the REST (RESTful) API and the SOAP API are the two most used techniques to create a programming interface for a web service. When comparing an HTTP request to paper media, we can say that the REST API sends requests via basic notes most of the time, and a letter in an envelope once in a while (perhaps writing part of the message on the envelope itself as well). The SOAP API, on the other hand, sends all instructions in the form of a detailed letter in a standard format, with simply an envelope (a single HTTP request) as a delivery method.
REST APIs are used when clients and servers solely work in a web environment, where object information isn't important and multi-call transactions aren't required. Microservices, on the other hand, is configured for SOAP APIs if a rigorous contract between the server and the client is required, as well as the ability to perform extremely demanding multi-call transactions with high security and no bandwidth issues.
API Testing Tools
For a QA specialist, the lack of UI elements can be perplexing — there are no buttons, fields, or a clear format for addressing the services. Interacting with the API is made easier with special tools. SoapUI and Postman are the most popular.
SoapUI — an open-source tool for testing Soap and Rest APIs. In September 2005, SoapUI was first released on SourceForge. It's open-source software with a European Union public license, and it’s been downloaded over 2,000,000 times since its initial release. The user interface is created using Swing and is totally based on the Java platform (i.e., SoapUI is cross-platform). Web service validation, startup, development, modeling and layout, functional testing, and load and compliance testing are all included in its capabilities.
SmartBear, a software development company, has also built a commercial version of SoapUI Pro (now named ReadyAPI), which focuses on performance-related features. SoapUI can perform HTTP(S) and JDBC calls, as well as test SOAP and REST web services, JMS, and AMF. Automated scripts are written in the Groovy programming language.
Postman — a Swiss army knife, according to its developers, that allows you to form and run queries and document and monitor services all in one spot. From within Postman, testers can develop tests and perform automated testing.
Postman’s primary function is generating collections using API queries. Collections make it easy to store queries for an application you're testing or building, and a newbie to the project can rapidly learn how to use the program. Additionally, the development team may easily design the API using Postman. Postman's automated scripts are written in JavaScript.
How Cucumber and Spock Became our Go-to Guys
SoapUI and Postman both have their own set of characteristics. Such tests are difficult to maintain, and storing them in version control systems (such as git) is problematic.
SoapUI and Postman, despite their widespread use in automated testing, can only run tests locally and cannot be used in integration systems like Jenkins. Our team chooses Cucumber and Spock to handle this challenge, as it’s possible to conduct Jenkins tests remotely using them. Furthermore, these frameworks enable the creation of automated smoke-tests that run during the installation of an application, something also not possible with Postman or SoapUI.
Features of Cucumber and Spock frameworks
Spock and Cucumber exemplify the philosophy of behavior-driven development (BDD). The principle behind BDD is that you must first define the desired result of the added feature in a subject-oriented language before writing any tests. The developers are then given the final documentation.
A behavioral specification has the following structure and is delivered in a semi-formal format:
Title — a description of the business objective given in the subjunctive form.
Narrative — answers for the following questions in summary form:
Who is the stakeholder in the story?
What is included in the story?
What is the value of the story for the business?
- Scenarios — One or more cases may be included in the specification, each revealing one of the user behavior situations.
A scenario usually follows the same pattern:
One or more initial conditions (Given)
The event that triggers the start of the scenario (When)
The expected result or results (Then)
BDD does not provide any formal rules, but it does require using a limited standard set of terms that encompass all aspects of the behavior specification. Dan North, the founder of BDD, developed a template for specifications in 2007, which quickly gained traction and became known as the Gherkin language.
Cucumber is one of the most widely used BDD tools nowadays. Its authors aimed to bring together automated acceptance testing, functional requirements, and software documentation into a unified format that could be understood by both technical and non-technical project participants.
The test scenario description is built around the Given, When, and Then stages. Each stage corresponds to an annotation that associates a method with a string in the scenario's text description using a regular expression. Scenarios are made up of test steps that each define a specific functionality or feature.
To automate the scripts given in Cucumber, you can use Ruby, Java, and Python. The test is stored in a separate file with the extension *.feature and is written in Gherkin notation. One or more scripts — which can be written by BAs or manual QA specialists — may be included in this file. The test automation expert then generates a separate class that has a programming language implementation of the steps.
While building scripts for the behavior of the API application I was testing, I became acquainted with the Cucumber framework. To be more precise, it was not Cucumber itself, it was the Gherkin language, and we were attempting to describe application behavior scenarios using BDD rules. This was a fascinating experience from the perspective of a manual tester. On the crew, there were several manual testers who wrote Gherkin scripts. The key issue was getting everyone to agree on a standard structure for describing each step and generating a set of procedures that could be repeated in different tests without being duplicated.
Feature: Test OpenWeather API
As a customer
In order to check weather
I want to get my city name in response.
Scenario Outline: Check if city name is returned correctly
When Sent request to openweathermap for “<cityReq>”
Then Check that 200 response code is returned
And Server returns correct city name “<cityResp>”
Examples
| cityReq | cityResp |
| “Kharkiv, UA” | “Kharkiv” |
| “London, GB” | “London” |
The script for testing an OpenWeather API application in Gherkin notation is shown above. For this example, I created a simple script that sends a request to an application server with specific parameters and then checks the answer.
public class Stepdefs {
@when ( “Sent request to openweathermap for {cityReq} “ )
public void sent_request_to_ openweathermap ( String cityReq) {
HTTP Builder http = null;
try {
http = new HTTP Builder (testUrl);
String [ ] actualCity = cityReq.split ( regex: “, “ ) ;
...
An example Java Stepsdef class is included in the code. The annotation (@Given, @When, @Then, etc.) and the text from the feature file are used to map each step from the feature file to its implementation in the Stepsdef class.
Cucumber is merely an activator for BDD — you must follow BDD principles to get the most out of it.
Spock is a testing ground. Some would even call it "a language built on top of Groovy." On another project, where I was acting as an automator, I used Spock. As I previously stated, the execution scripts are separate from implementing each construct in Cucumber. This produces understandable scripts, although it’s time-consuming. Because of this, when writing an implementation, this strategy may be impractical.
The steps are described and implemented in Spock in a single Groovy class. The framework is compatible with all popular IDEs (in particular IntelliJ IDEA), multiple build tools (Ant, Gradle, Maven), and continuous integration services because it’s built on JUnit (continuous integration). A test class is a collection of scripting methods with names in quotes that are similar to Cucumber script names. Because these classes are derived from JUnit, they may be performed like ordinary Groovy unit tests from the IDE. We get regular JUnit results at the same time, which is really useful when designing and debugging automated tests.
Each test step is broken down into its own code block in Spock, which begins with a label and ends with the start of the next code block or the end of the test. The Given block is in charge of establishing the test's initial circumstances. The system stimulus is represented by the When block, and the system response is represented by the Then block. Both of these blocks are always used in tandem. One Expect block can be utilized if the When-Then construct can be reduced to a single expression.
class WeatherTestSpec extends Specification {
@Shared def testUrl, testResponse
def setupSpec () {
testUrl = “http:// api. openweathermap.org”
testRequest = [ ‘APPID’ : “aaa” ]
testResponse = ‘ ‘
}
def ‘ Check if city name and coordinates is returned correctly’ () {
when: "Sent request to openweathermap"
def http = new HTTPBuilder(testUrl)
testRequest.put ( ‘q’, cityReq)
testResponse = http.get( path : ‘/data/2.5/weather’ , query : testRequest )
then: “Check that 200 response code is returned”
testResponse. cod == 200
and: “Server returns correct city name”
testResponse. name == cityResp
where:
cityReq << [ “Kharkiv, UA” , “London, GB” ]
cityResp << [ “Kharkiv” , “London ” ]
}
}
A Groovy class with a Spock test is shown in the example above. The step description appears after the ":" sign and is an arbitrary string. It’s not, however, a required component. Spock enables you to create a test specification without having to describe the procedures. This method, however, is not widely recognized, and it can make it harder to grasp test logic in the future.
Which One’s Better?
Cucumber and Spock both have a strong relationship between the human language specification and the test code. This is a direct result of both systems being built to accommodate the BDD paradigm. Cucumber, on the other hand, takes it more seriously. If no regular method expression matches the given step text, large modifications to the human language step description will break the test code — for example, with a missing step implementation. After the ":" character, the text for Spock is an arbitrary string. The step's description is double-checked for consistency before it's put into action.
Cucumber properly distinguishes between the human-readable specification and the test code. This is really useful for non-technical experts who write or read specs, and a strong collaboration between the Product Owner, BA, QA, architects, and developers is at the heart of BDD. In the case of Cucumber, all project participants will agree on and understand the specification before development begins.
Spock, on the other hand, provides a quick, succinct, single-file answer. Individual test scripts can have easy-to-understand names due to Groovy's flexibility to use any string as a method name. Spock allows developers to read and understand the specification as well as the code that implements it from a single location. Let's also not forget about the extra benefits that come with Spock (e.g., advanced data table features).
Cucumber is also only useful for integration testing. Spock, on the other hand, can also be used to run unit tests.
It wouldn’t be helpful to categorically state which of these approaches to API testing is superior. At NIX United, we use both based on our tasks and objectives. When there are no automators on the team (or only a few), SoapUI and Postman are ideal for the early phases of automation. It's more rational to transition to Cucumber or Spock as the team grows. Each of these frameworks has its own set of benefits that make QA specialists' jobs easier and the testing process more efficient.
Oldest comments (0)