In today’s world of Agile development, developers are churning out code at blistering rates. An emphasis on rapid change puts them under pressure to develop code that “just works” without giving much thought to documentation or testing. This is especially the case with API endpoints. It’s easy to see how developers could bypass documenting and testing their API’s. It’s easier to write code that works, than it is to explain how it is used and ensure that it functions as it should. However with API endpoints, documenting and testing are two activities that can greatly serve companies in the long run.
The first step in our process is Documentation. RESTful web services are some of the most common, efficient, and easily understood backend application protocols. REST stands for REpresentational State Transfer, an architectural style and approach to communications. It is based on 6 guiding principles; separation of the client and server, stateless requests between the client and server, cacheable response data, a uniform interface, a layered system, and the ability to extend client functionality by downloading new code when necessary. When the API is pushed to the testing environment, we begin the process with documenting all endpoints in the API. This is conducted by listing all of the requests for each endpoint, then developing test cases for each request. Each request consists of several components; a url, an HTTP method type, headers, and parameters. All of these should be documented in a test plan.
In order to thoroughly develop the test cases, we cover all the bases by first testing for the successful request and then creating scenarios in which the request would fail. The failing test cases are developed by manipulating the request components in an improper way (i.e. using invalid parameters, omitting headers, changing request methods). To ensure reproducibility, the developed test cases include a scenario description, an endpoint url, headers, the HTTP method, body or query parameters, an expected status code, the actual status code, and the HTTP response given by the request. An added benefit to this test case documentation is that developers are given an example of a properly formatted request, at least in the successful test cases.
The next step is testing. Once the test cases have been developed, we begin to manually test them using our prefered tool, Postman. Postman is an API Development Environment (ADE) that enables users to create, edit, and execute requests, among other functionalities. In Postman, APIs are represented in the form of a Collection, which is a group of the requests used by an API. The Postman Collection is what we use to conduct the tests. Manual testing is performed by modifying the API requests in the collection as specified by the test cases, and executing them using Postman. Then the response and actual status code are recorded for each test case.
The second stage of testing is test automation. After manual testing is completed, the tests are automated using a node.js test automation suite comprised of javascript files that execute the test cases for all endpoints in the API. The automation suite also includes several node.js frameworks such as Mocha and Chai for assertions and reporting. In the framework, each endpoint is represented by a JavaScript file. The files include the urls for all requests related to the endpoint along with the headers for each request. Each endpoint also has a corresponding test folder containing javascript files for each related request. The endpoint test files contain scripts that run every test case related to a specific endpoint request. Another script in the automation suite executes all of the test scripts in sequence, essentially performing an end-to-end test on the API. Once the suite is finished running, a report is generated, containing information on the results of all test cases in the suite. When the automation suite is ready for use, it can be pushed to a central repository.
With this suite, developers will easily be able to leverage CI practices.
When a developer commits API changes to the central repo, the test suite automatically executes, and if it fails, a report is automatically sent to the developer. As a result, developers are able to quickly resolve API integration issues, saving time, and allowing them to focus on other high-priority tasks.
Although API endpoint testing may seem tedious, especially the documentation, it is a necessary process. For one, it provides clear examples of the API requests and their behavior in various situations. If the API is easy to understand, new users will spend less time learning it, and can be productive sooner. When API updates are needed, they can be made faster, as users will have a firmer grasp of the API. Also, by clearly defining the conditions of each test case, reporting becomes even more effective. After tests, developers are given specific details about API requests in failing test cases. This is especially useful, because they will spend less time identifying the conditions that cause issues, than resolving those issues. Overall, more of your company’s time will be spent efficiently, and you can be confident that you’re producing a high quality product. At Quilmont, automated testing is one of the many services we offer our clients in producing top-notch products. We are a tool agnostic company that prides itself on adaptability and providing high quality solutions at a rapid pace. Contact us today for a demo on Test Driven Development utilizing tools like Postman with Git, Appium, and Selenium. See how we can help you produce world-class products with our solutions