I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

Recently, the standards of testing have undergone a makeover from top to bottom. To move toward a modern delivery pipeline, such as continuous integration or continuous delivery, teams need to be at least versed in automation, and focus must shift upon preventing bugs by building in quality upfront and efficiently. Developers, product managers, business analyst and QA team members must begin by planning and building a better testing portfolio. As they start working closely together, they will begin to identify what they need to meet the acceptance criteria and determine as a team what the best way to test is. This also requires following the "testing pyramid methodology" by creating more lower-level tests -- API tests, for instance -- creating a smaller percentage of UI tests in the end.

This journey starts with RESTful API testing. At the end of this article, you will have a better understanding of why API testing is necessary, its key physical and logical layers, how to design a testing blueprint for APIs, and the technologies available to help.

What is a RESTful API?

In simple layman's terms, REST is a way for two computers to communicate with each other over the internet. One acts as a web browser, and the other acts as a web server. The transfer happens over the web, which communicates through HTTP/HTTPS protocols. The HTTP request methods performed are GET, PUT, POST and DELETE.

The two commonly used methods are GET and POST:

GET is used for retrieving data from a specified resource.

POST is used for creating data to be processed to a specified resource.

An example of this is the GitHub API for repository_url, shown below:

The moment the HTTP request is fired it will begin communicating with the layered architecture.

Review the REST Layered Architecture

The REST layered architecture is simply a software design pattern that is implemented in a stack of layers. The traditional layers help you better organize the code. For instance, an application can have the following layers: presentation, business Logic, data access and data storage.

Presentation

The top-most layer of the application is the user interface, which translates the response into machine readable format for users to understand. The presentation layer takes care of content representation, shown here:

Business Logic

The logical layer is the brains of the application. This layer processes and communicates the data between the layers and makes logical decisions. Some "logical" decisions the logical layer makes include the handling of the API, authentication and authorization, auditing, and exception handling.

Data Access

When designing your RESTful API testing strategy blueprint, it is important to outline all the activities that will be carried out for a sprint and the release.

The data access layer provides simplified access to data stored -- database, flat files and more -- separate from business logic and presentation code. It is tightly coupled with the data storage layer.

Data Storage

The data storage layer will consist of a relational database management system, NoSQL database, file system, remote storage in the cloud or in-memory.

Design an API Blueprint for Development and Testing

When designing your RESTful API testing strategy blueprint, it is important to outline all the activities that will be carried out for a sprint and the release. Having a clear testing strategy will increase the collaboration and communication early in the sprint, rather than towards the end. Often, teams see an uptick in productivity when everyone on the team takes on more ownership, responsibility and accountability for product quality.

User experience pyramid

When launching and maintaining an API, the entirety of the team needs to consider every aspect of the API user experience. This pyramid represents the different API characteristics the team should consider:

Selecting a Testing Technology

The options can be overwhelming; there are lots of open source tools, vendor tools and custom testing harnesses. It's useful to think practically about your requirements while evaluating any testing technology.

Test Coverage

To build quality products that everyone raves about requires a well thought-out testing strategy. It starts early in the process of writing code by writing tests in parallel during the sprint. This will lead to better design and fewer bugs. Unit tests are the backbone of any test strategy.

Defining Standards

It's critical to establish standards upfront and communicate them to everyone on the team. This will help avoid, for instance, general testing and coding headaches caused by unexpected changes or inabilities to scale. Continue to evaluate and recalibrate along the way.

Responsibilities

Continuous Testing

Continuous testing is not only about the implementation of API tests. It is first and foremost a strategy, then a tool selection and then an implementation of more than just API tests. Once set up, and when backed by great analytics, continuous testing improves the quality of applications and entire delivery chains.

Technologies for RESTful API testing

The most common challenge for any type of automated scripting is locating the right technology for the project. I have found that many teams never get past this phase due to several reasons:

Unawareness of all the available tools or testing frameworks.

A lack of the expertise or knowledge needed to customize and deploy an existing framework.

An inability to afford the cost of vendor tools.

No available time or resources to build a custom testing harness from the bottom up.

Here are some of the tools or frameworks are widely used for automating API testing:

Conclusion

The testing strategy is not just a piece of paper. It's the reflection of all the activities -- development, testing and the continuous loop of feedback. It improves the entire delivery chain by providing fast feedback and allowing the possibility of iterations during the sprint. And it will allow you to release your RESTful APIs to the wild with confidence.

Join the conversation

5 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

The most challenging part is not in technical details but in getting a "traditional QA" onboard. I, as a tester-developer hybrid, only welcome having the ability to test early, and to test components in isolation, but doing API testing does require certain "mind shift" from traditional manual test cases.

The article is pretty big and covers a lot. One particular aspect that deserves a heavier focus is data testing. All these REST calls are the black boxes that accept input and provide output of data. So calling a service once might be sufficient to check whether it's app.To check whether an integer parameter is properly handled we'd need more samples, like:

Try non-number

Try a number out of the logical range

Try a number with heading or trailing spaces

Try numbers right at the lower and upper boundary

Try sending empty or non-existing id

After I checked a REST in isolation I test integration scenarios, including monitoring of the turnaround time.