In the realm of software systems, the concept of application programming interfaces (APIs) is commonplace. Often, you'll find services or components in these systems that are deployed with over-the-wire APIs. But, what do these APIs entail? Are they exclusive to backend services instructed by various user interfaces via some remote access protocol such as HTTP? Not quite. The term "API" may typically be used in this context, but it isn't necessarily limited to it. In this exploration of API testing, we are defining an API as a remote backend service that is an integral segment of a software system.
So, what exactly is API Testing?
API Testing, in a nutshell, involves examining the test surface of an API, which is usually a deployed service layer interface. This testing schema has evolved over the years and it predominantly involves transmitting HTTP requests to a deployed service and subsequently parsing the HTTP response received. The essence of this process is to ascertain and verify that the payload returned aligns with your expectations.
Conventionally, such APIs will have real user interfaces that call upon them. However, in API testing, this layer is bypassed in the quest for more granular testing. But is this approach what service tests, as depicted in the middle part of the test pyramid, represent? Let's clear that up.
API Testing and the Test Pyramid
According to Mike Cohn, the creator of the test pyramid model, service tests pertain to logical business services. His view of service tests does not outwardly clarify that they are deployed services tested over a remote API. In other words, service tests bring to view a broader breakdown of code that provides a full business function to the application, instead of restricting to just single class or method testing as in unit tests.
However, terminology confusion arises in the tech industry when certain words carry multiple meanings based on context. 'Service,' in relation to software development, is one such word, and unfortunately, the middle layer of the test pyramid succumbs to this semantic trap.
Automated Tests with API Testing Tools
The industry is inundated with several tools that have been designed to write and execute automated tests against a deployed services API. An example is Postman, a tool that houses saved HTTP GET and POST operations and allows tests of varied kinds to be written on the responses of these operations. This helps to confirm either the HTTP status code in the response or perhaps, the response body.
Consider an HTTP GET call to a prescription application - you can order a retrieval of prescribable medications from the API and get the results immediately. If you desire, you can even design a test to scrutinize and verify the expected values in that response.
Most of these API tools require subscription for sustained company usage. Alternatively, unit tests using a network or wire library can be written to test an API in place of a dedicated tool like Postman. However, it's key to note that the choice of tool depends entirely on the tester's preference and comfort.
The Purpose of API Testing
The specific objectives that necessitate API testing are often for regression and smoke purposes - a term unseen till now but will be discussed soon. Essentially, automated tests against an API are predominantly configured not to aid in the construction of new builds but to detect issues in prior work. This form of testing, like a deployed API, has an inherent test surface targeted.
On the technology front, API testing is a highly technical type of testing that doesn't generally require dedicated coding sessions, but demands familiarity with protocols used for sending requests and receiving responses from the API. Currently, REST over HTTP with JSON data as the payload stands as the popular choice. Tools like Postman are widely-accepted in this space, but a multitude of other options are equally available.
The Pros and Cons of API Testing
API testing offers optimum leverage when the product in question is a service. In this scenario, there's no UI that the team builds or controls - their task is solely to create one or more services that other teams or products then utilize. Such a team will most certainly incorporate automated API testing.
Furthermore, if the application utilizes a multi-service or micro-service architecture, API testing provides a substantial benefit. Another instance where API testing triumphs is when the service layer comes with its inherent complexity, complete with logic built into it as a part of the configuration rather than the deployed code. An example is an API gateway, commonly used in modern times as a front-end for services with complex features that require extensive testing - a task aptly handled by API test automation tools.
On the flipside, API tests can be slower compared to unit tests due to the myriad components being tested "over the wire" in a live service environment. As such, API testing might not be the best choice for testing the domain logic implemented in the code behind the API. In these cases, unit testing or functional testing can be a superior option.
The varied facets of API testing – including technical, testing tools, methodology, and pros and cons - show that there are numerous factors to consider when selecting the ideal approach for your system. This reinforces the importance of thoroughly understanding your system architecture and capabilities to ensure optimal testing practices.