Testing the Client Side of RESTful Services (Without Using Mocks)
DZone's Guide to
Testing the Client Side of RESTful Services (Without Using Mocks)
Join the DZone community and get the full member experience.
Join For FreeSensu is an open source monitoring event pipeline. Try it today.
People tell me A and B, They tell me how I have to see, Things that I have seen already clear, So they push me then from side to side (I Want Out - Helloween)
Developing an application that uses RESTful web API may imply developing server and client side. Writing integration tests for the server side can be as easy as using Arquillian to start up server and REST-assured to test that the services works as expected. The problem is how to test the client side. In this post, we are going to see how to test the client side apart from using mocks.
As a brief description, to test the client side, what we need is a local server which can return recorded
JSON responses. The
rest-client-driver is a library which simulates a
RESTful service. You can set expectations on the
HTTP requests you want to receive during a test. So it is exactly what we need for our java client side. Note that this project is really helpful to write tests when we are developing
RESTful web clients for connecting to services developed by third parties like
Flickr Rest API,
Jira Rest API,
Github ...
First thing to do is adding
rest-client-driver dependency:
<dependency>
<groupId>com.github.rest-driver</groupId>
<artifactId>rest-client-driver</artifactId>
<version>1.1.27</version>
<scope>test</scope>
</dependency>
Next step we are going to create a very simple
Jersey
application which simply invokes a get method to required
URI.
public class GithubClient {
private static final int HTTP_STATUS_CODE_OK = 200;
private String githubBaseUri;
public GithubClient(String githubBaseUri) {
this.githubBaseUri = githubBaseUri;
}
public String invokeGetMethod(String resourceName) {
Client client = Client.create();
WebResource webResource = client.resource(githubBaseUri+resourceName);
ClientResponse response = webResource.type("application/json")
.accept("application/json").get(ClientResponse.class);
int statusCode = response.getStatus();
if(statusCode != HTTP_STATUS_CODE_OK) {
throw new IllegalStateException("Error code "+statusCode);
}
return response.getEntity(String.class);
}
}
And now we want to test that
invokeGetMethod really gets the required resource. Let's suppose that this method in production code will be responsible of getting all issues name from a project registered on
github.
Now we can start to write the test:
@Rule
public ClientDriverRule driver = new ClientDriverRule();
@Test
public void issues_from_project_should_be_retrieved() {
driver.addExpectation(
onRequestTo("/repos/lordofthejars/nosqlunit/issues").
withMethod(Method.GET), giveResponse(GET_RESPONSE));
GithubClient githubClient = new GithubClient(driver.getBaseUrl());
String issues = githubClient.invokeGetMethod("/repos/lordofthejars/nosqlunit/issues");
assertThat(issues, is(GET_RESPONSE));
}
- We use ClientDriverRule @Rule annotation to add the client-driver to a test.
- And then using methods provided by RestClientDriver class, expectations are recorded.
- See how we are setting the base URL using driver.getBaseUrl()
With
rest-client-driver we can also record http status response using
giveEmptyResponse method:
@Test(expected=IllegalStateException.class)
public void http_errors_should_throw_an_exception() {
driver.addExpectation(
onRequestTo("/repos/lordofthejars/nosqlunit/issues")
.withMethod(Method.GET), giveEmptyResponse().withStatus(401));
GithubClient githubClient = new GithubClient(driver.getBaseUrl());
githubClient.invokeGetMethod("/repos/lordofthejars/nosqlunit/issues");
}
And obviously we can record a put action:
Note that in this example, we are setting that our request should contain given message body to response a 204 status code.
This is a very simple example, but keep in mind that also works with libraries like
gson or
jackson. Also
rest-driver project comes with a module that can be used to assert server responses (like
REST-assured project) but this topic will be addressed into another post.
I wish you have found this post useful.
We keep learning,
Alex.
Sensu: workflow automation for monitoring. Learn more—download the whitepaper.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Alex Soto , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}