Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Automated Testing of REST Services

DZone's Guide to

Automated Testing of REST Services

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

Despite the fact that I’m a Java and Scala developer I still passionate about testing software, to be more precise– web applications. It’s really interesting to develop web app and be confident that the apps are of good quality.

When I’ve started a career the most popular web architecture was MVC (Model View Control) and that was pretty simple. When you develop some business logic you have to write some unit tests which check a functionality of internal controller functions and this is enough. Integration tests were more complex task at that time because such tests imply usage of some mock frameworks.

But the time moves on. And the old MVC architecture has become insufficient for numerous client types such as smartphones, tablets, browsers. REST architecture started to substitute the MVC pattern. More and more apps started use one API to communicate with different clients via HTTP. This circumstance was more then innovative. Because all business logic related to data and data processing was concentrated on servers meanwhile the client-side was responsible for representation of the data and some extra manipulation with it.
As you probably guessed I just described a principles which are used in a Single Page Application approach (SPA). In this manner built a lot of modern apps Facebook, Instagram, Twitter.

While developers have changed their apps, the ways of testing were mutate too. As a result appeared a new layer on which testing was not just applicable but was very efficient. I talk exactly about API layer. Since an API is consumed by different clients (smartphones, desktops…), make sense to gather a group of tests which check a common logic for all types of clients and to highlight the client-specific test scenarios to focus on a client specific logic. The logic works with data which was already tested in API layer.

Such approach gives us an amazing testing strategy. Testers save time, because they do not need to repeat tests on different clients by interacting with already tested data sets. They just need to pay all attention to a UI and some specific features.

Automated testing of REST-services

In my own experience I perform testing of REST API layer by writing automated test scripts. For this purpose I use REST-assured library developed by JayWay company. This java library is really strong weapon for automated testing of REST-services.

The code of such tests looks really nice:

@Test
    public void getLandLaordTest() {
        given()
            .contentType(ContentType.JSON)
            .pathParam("id", "DoYlvMXN")
        .when()
            .get("/landlords/{id}")
        .then()
            .statusCode(200)
            .body("firstName", equalTo("Sam"))
            .body("trusted", equalTo(false));
    }

It’s pretty concise and not verbose at all. One more advantage of REST-assured usage in a java projects is its simplicity. I can teach any member of my team to develop such tests in a 3-4 hours. Also it works well with the most popular java testing frameworks such as TestNG, JUnit and Hamcrest.

Summary

I recommend to test code you write because it lifts you on a next level of software development competences. Automating of work is a key to success and investment in saved time.

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}