The standard practice of testing web applications for many years was heavily front-end graphic user interface tests....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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:
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.
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.
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.
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.
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.
Clearly outline each team member's responsibilities for developers, QA, DevOps teams and product managers.
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:
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.
It's time to start rethinking the nature of RESTful API security
Why RESTful APIs aren't the only way to access object storage
What does the future of RESTful APIs hold for developers?