REST ASSURED : Testing API endpoints
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. REST-assured provides a lot of nice features,such as DSL-like syntax, XPath-Validation, Specification Reuse, easy file uploads and with those features we will handle automated API testing much easier.the preferred and current way is to use the newer BDD (Behavior Driven Development) like given-when-then syntax.When you create BDD features, the majority of its scenarios will be made up of three main Gherkin keywords: Given, When and Then. Each one has a particular function:
Given = a context/Getting a system in a particular state
When = something happens/Poke it
Then =we expect some outcome/examine the new state
Why REST-assured?
Let’s look at what is expected from a tool that helps in writing automated tests for REST APIs and how REST-assured lives upto these expectations.
Easy HTTP Request Building and Execution : Requesting building comprises of defining many things like query params, cookies, headers, path params and request body. Using it’s DSL, REST-assured hides away the complexity of building and executing an HTTP request behind a fluent interface. We will see this in action in the next section.
Response Assertions : REST-assured also handles, within its library, the parsing of responses. It provides many constructs for making assertions on cookies, response headers and response body. For doing assertions on response body it provides JsonPath for assertions on JSON responses and XmlPath for assertions on XML responses. It also also uses Java Hamcrest Matchers to make readable assertions.
Ability to write Clean Code : The real value of automated tests is realized when they are easy to understand and takes very less effort to maintain them. In the dictionary of REST-assured’s DSL, you can also find constructs for writing in
Given-When-Then style. Using this style helps in specifying pre-conditions under the Given section, behavior under test under the When section and verifications under the Then section. This helps in maintaining a clear separation of concerns within a test, thus leading to a very readable test.
Given-When-Then style. Using this style helps in specifying pre-conditions under the Given section, behavior under test under the When section and verifications under the Then section. This helps in maintaining a clear separation of concerns within a test, thus leading to a very readable test.
Lets’ take a look at examples:
1.I want to get list of all countries.The example is as:
RequestSpecification request=new RequestSpecBuilder().build();
ResponseSpecification response=new ResponseSpecBuilder().build();
ResponseSpecification response=new ResponseSpecBuilder().build();
@Test(enabled=true)
public void getAllCountries()
{
given()
.spec(request)
.get(API_ENDPOINT_FOR_GETTING_ALL_CONTRIES)
.then()
.statusCode(200);
}
public void getAllCountries()
{
given()
.spec(request)
.get(API_ENDPOINT_FOR_GETTING_ALL_CONTRIES)
.then()
.statusCode(200);
}
Here we are making get request to API_ENDPOINT and checking for statuscode 200.
Now lets see how to pass queryparams in get request.Suppose i want to pass ContryCode and get all cities.The request looks like:
@Test(enabled=true)
public void getAllCities()
{
given()
.spec(request)
.queryParam(“countryId”, “AR”)
.get(API_ENDPOINT_FOR_GETTING_CITIES_BY_COUNTYID)
.then()
.statusCode(200);
}
public void getAllCities()
{
given()
.spec(request)
.queryParam(“countryId”, “AR”)
.get(API_ENDPOINT_FOR_GETTING_CITIES_BY_COUNTYID)
.then()
.statusCode(200);
}
Comments
Post a Comment