An API (Application Programming Interface) is a layer or a tier of an application which carries out data processing and coordination between other tiers, as well as with third party applications. Basically, it is an interface purposed for computer interpretation as opposed to human.
An API is often associated with the logic tier of a product, and it is not uncommon for the logic tier to consist wholly of an API, although it is not necessarily so for some of more complex products.
So, what’s so important about testing an API and doing it right? Aren’t common test approaches good enough for testing API-based products? The answer to this question is both yes and no. “No” is what we are going to speak about further along.
What makes a successful API product?
Challenge: When to start testing?
Business people (customers) look at the final product from a very different aspect than developers and testers do, and are more concerned with overall functionality. As a result, the importance of testing during initial development stage is often underestimated. To reduce the project’s cost, “redundant” testing efforts are cut, leaving only the most essential minimum. This approach may lead to the need to introduce major changes close to the project’s finish line, which is a lot more costly and can endanger the deliverable.
Based on our experience, this risk is especially relevant for API-based products, since most effort is typically put into developing and testing a rich front-end part, not the API itself.
To deliver a truly successful API product, verification engineers have to be involved in the design and development process from the very beginning. Otherwise only positive testing approach is used, which only shows product behavior in ideal conditions which are never true for the end user. In the end – additional time spent for fixing the emerging issues after products release, and for providing user support.
Given what was said, you should always plan sufficient time and resources for testing in the initial stage. That way, most issues can be prevented even before they arise, leading to a more predictable result both from technical and financial viewpoint.
Challenge: White box testing
Since API-based products are specifically designed to be able to communicate with third party applications, it is crucial that all its internals are tested thoroughly. Such testing approach, which we know as white box testing, includes verification of individual data paths and operations of the application. Speaking about black box testing, it only deals with inputs and outputs of the product, leaving the essential functionality details “in the box. Taking into account the specifics of API-based products, white box testing is a must; however, sufficient knowledge about the product internals is required in order to verify it properly.
White box testing for API-based products is usually a laborious process, requiring preliminary research and deep insight into the solution. As distributed and scalable as API products may get, extra time and effort are needed to make sure that all the parts and connections in this complicated infrastructure are working properly.
API-based products testing: What’s the solution?
PLVision’s kuTest tool for automated testing takes into account all of the crucial aspects of testing API-based products, ensuring high quality both on the development stage and afterwards. Even white-box testing approach gets easier thanks to kuTest features specifically designed for API testing facilitation.
kuTest verification tool: Advantages for API-based products
- The API needs to be described only once in kuTest, thus eliminating the need to research the solution deeply before each testing cycle.
- Modularity – Change in API of the product will not require changing the set of tests or methods. Change of API protocol will only affect wrappers modification (proper description in the Test Framework), but tests and API description will be the same, which is the best option to save time and resources in case of product migration to new API syntax , or adding of new version of product.
- In kuTest, the API of products is described in YAML-based format, with all dependencies between tables, data type, fields’ format and syntax. Basically, the set of tests remains the same; all that’s needed is to describe the pattern of each field or field type in YAML.
- Method wrappers were created for work specifically with APIs (CRUD).
- Test suite is customized for syntax validation of fields depending on data type.
- A Separate test suite exists for functionality validation.
- kuTest is a py.test-based testing tool, which provides all the benefits of py.test and test automation approach.
More about kuTest here.