Application programming interface – API Testing (White Box Testing)
An interconnected world dependent upon proprietary business networks is dependent upon the ability to share data, the principle mechanism for doing so is the application programming interface, otherwise known as the API. Despite the clear importance of API testing, it is sorely neglected due to a lack of awareness of the business value.
Business growth is increasingly dependent upon the internet of things and real time feedback, where software updates can be a product in their own right, – enabling devices, adding new features or providing access to private databases and premium subscription content. This nothing new; it was never an ’if’ this internet enabled revolution would take place but rather a ’when’. The falling cost of embedded electronics has made connecting every day consumer devices such as fridges, boilers and cars affordable and consequently mass market.
API testing is vital to meet the expectations of unforgiving consumers, to ensure the seamless integration of new features, push bug fixes remotely (even before the user has encountered the problem), as well as to share data securely. API testing improves the quality of the final product and is essential to ensure compliance with industry standards. Despite this, API development is one area that is typically neglected by both business analysts and project managers alike. Consequently, API testing is typically underfunded, resulting in code that is self tested or not tested at all.
What you need to know about API testing
In the world of application testing, API testing is pretty much top of the food chain. This is because it requires white box testing, a verification technique that software engineers often use to examine if the code works as expected. Testers need to have an internal perspective of the system and extensive programming knowledge, necessary to design the test cases for white box testing. When determining the extent of testing necessary, equivalence partitioning and boundary value analysis is used to predict the number of test cases necessary. When examining error prone test cases, it is vital that the tester can effectively measure how thoroughly the test cases exercise the code. What we are talking about here is the use of parameterized testing, and a testing framework such as JUnit, an open source framework used for writing and running tests in JAVA (xUnit used for testing in other languages).
When looking at the API as a 3 tiered structure (image) there is:
- Presentation Layer
- Business / Logic Layer
- Database / Data Layer
The API connects the Presentation Layer (user layer) to the Database / Data Layer which is why it is vital that any changes to the API are made very carefully. This is highlighted by the explosion of DevOps on the scene of application development, where continuous testing enables continuous improvement, ergo – continual change, – where any change can potentially damage the user experience. Consequently the use API versioning is essential to ensure backwards compatibility. If new changes can potentially break code using the API, then this should be in a new version. Any new version should be made available with the API version number recorded in the API url. Customer loyalty evaporates when users encounter broken API’s, so plenty of warning should be given to the user base prior to any new release.
API Design should be according to the open / closed principle of object-orientated programming, with software entities open for extension but closed for modification. Equal weight should be given to functionality, reliability and usability of the API, taking a holistic approach to design, – ensuring input from every potential stakeholder or potential user group is essential in determining the API’s potential uses (demand management). Establishing a business value for the lifetime of the API is essential for prioritizing features and determining the API requirements for development (Requirements Management).