The shift to microservices and API-driven architectures is driving significant innovation across the industry, but it is also putting companies at risk. The human interface (Web and mobile UI) is no longer a major business risk. Instead, the biggest holes are hidden in the API’s non-human interface.

As a result, API testing has become a growing concern, but we keep hearing “What is API testing and why do we need it?”

A quick summary is that an application programming interface (API) is a way for applications to communicate with each other using a common interface governed by a defined contract. The driving force behind the adoption of API testing is the ability to test the application’s business logic in a stable manner independent of the UI. API testing allows for more comprehensive testing, such as performance and security testing, than testing only on the front end. Industry analysts and agile experts such as Martin Fowler and Mike Cohn agree that API testing is a must. So what’s holding us back?

Impact of test invalidation

Software teams want to spend ideal time, not just testing and debugging, to maximize the potential of successful projects. However, it has traditionally been difficult to reduce the time spent on testing and debugging because many serious errors and security holes are discovered late in the software lifecycle, including after release.

The following figure illustrates when defects are introduced into the application and the impact of timing on the cost of fixing defects at each stage. You can clearly see that the cost of late defects is significant — the increase in cost comes from a variety of factors (for example, the time it takes to diagnose the problem and determine the root cause, the number of people involved in the process, and the increasing complexity associated with fixing defects (and the risks associated with that).

If you think of yourself, “I’ve seen it before”… You probably already know that! In 1996, Capers Jones published the research behind this chart, and even though software development practices have changed over the past 20 years, the latest research is still relevant today.

What we want to accomplish: Test the pyramid

So where did we go wrong? The quality approach we are taking is wrong – we need to look at the table above and look for ways to detect left-shift defects and find them early, easier to diagnose and fix. Techniques such as in-depth analysis of code can be found immediately after the code embedded in the security and reliability problems in the code base, but in order to verify the runtime or functional behavior, we need to spend time on the creation and maintenance of automated tests, and, in the agile world, we need these test once created, to perform in a row, To enable them to “move left” to detect and capture regressions after implementing the new functionality.

The ideal way to spend time and organize a test portfolio is often expressed as a “test pyramid,” as shown below, which is achieved by trying to drive as much testing effort as possible on the development timeline. You start with the basics of unit testing, where bugs found are easy to fix, and then API, integration, component testing, and system and UI testing round out the layers of the pyramid.

But while practices such as test-driven development (TDD), early unit testing, and more automation in software testing have become mainstream, software teams still spend too much time on late-stage UI and system testing. We often describe the current situation as an inverted pyramid. However, a closer look at the data reveals a severe lack of API testing in the industry, so martini cups are more appropriate:

Unfortunately, the middle layer of the testing pyramid is generally not used because of the obvious advantages of investing in API testing. For example, tests can be done earlier in the software development life cycle (as long as API contracts/definitions are available), can be more easily automated, and are fundamentally less vulnerable to incoming changes in the application UI/UX.

By organizing API tests into common use cases, scenario-level tests can be created, and automation of API tests paves the way for early and scenario-driven performance and security testing. Ultimately, the investment in API testing enables teams to better manage change and achieve the agility promised by modern development methods. Do early testing often. What don’t you like? Unfortunately, the team is struggling to implement API testing for a variety of reasons.

What constrains API testing?

The biggest obstacle to the growing adoption of API testing is the actual creation of tests. It’s not easy to create meaningful tests that work at the API level, let alone string them together to create an appropriate test scenario. Equally important in preventing the adoption of API testing is the knowledge gap that exists between developers and testers. API testing requires knowledge and capabilities that testers typically lack, and managers don’t want developers to do integration or API testing.

Developers work from the bottom of the pyramid and are happy working at the unit level. It was their code (or at least their job description), and unit testing seemed a natural fit for their workflow. The automatic creation of unit tests increases efficiency at this level, and the software industry understands the need for comprehensive testing here.

Testers, on the other hand, work at the top of the PYRAMID at the UI level, where use cases and interfaces are intuitive and easily mapped to the original business requirements. Their view of the application is from the outside.

API testing lies between these two roles, requiring both knowledge of interface design and how to use them. Testers often can’t work at this level, seeing apis as code, and when developers learn about interfaces and apis, they often don’t have a complete understanding of how interfaces work with other subsystems, and therefore see API testing as functional rather than its scope of responsibility.

Until recently, there was a lack of test tool automation to help bridge the gap between unit and system testing and between developers and testers. To help the software industry get closer to the ideal Test pyramid and evolve from the Martini cups we see today, we introduced the Smart API Test Generator into Parasoft SOAtest, our functional Test automation tool that is easy to use and use.

Give up the Martini

Smart API Test Generator is a plug-in for Google Chrome Web browser that monitors manual testing and uses artificial intelligence to create automated API schema tests, reducing the technical skills required to adopt API testing and helping you build extensible API testing strategy teams and organizations. It goes like this:

The Intelligent API test generator monitors background traffic as you perform manual tests and sends it to its ARTIFICIAL intelligence engine, which identifies API calls, finds patterns, analyzes the relationships between API calls, and automatically generates a complete, meaningful API test scenario, not just a series of API test steps.

Make API tests more accessible

The Smart API Test Generator makes API tests easier for Test teams to use because these API Test scenarios are created using the testing practices they are already doing. Unlike manual or even automated UI testing, documented API activities help testers and developers collaborate better, their single artifact can be easily shared and understood by both teams, and can diagnose the root cause of defects better than complex UI testing, which requires the assembly of the entire application.

UI testing alone, on the other hand, often leaves developers and testers isolated in communication and debugging techniques — often resulting in long wait times and iterations between defect introduction, defect detection, and defect resolution.

The power of API test scenarios

The API interactions documented during UI testing require some form of organization into scenarios or use cases. The ARTIFICIAL intelligence of the SOAtest Smart API Test Generator helps by creating schemes based on relationships between different API calls.

Without the help of the Smart API Test Generator, users would have to spend time researching their Test cases, finding patterns, and manually establishing relationships to shape each Test scenario. In addition, Parasoft SOAtest provides an intuitive, UI-driven way to describe assertions, allowing testers to perform complex assertion logic without writing any code. Otherwise, users will manually code each assertion, and they may miss an assertion or set it to error. You can then use visual tools and tool-assisted logic to extend these API tests to create a broader suite of tests.

conclusion

While software teams admit to wanting to achieve an ideal distribution of unit, API, and UI testing, the reality is that your average team is doing an average of unit testing and still relies on late UI and system testing. API testing provides an ideal communication mechanism between developers and testers and has a highly maintainable level of automation that can be extended to performance and security testing.

Moving these tests to the left and performing them earlier in the software lifecycle means finding critical security and architectural defects early, where they are easier to diagnose and less risky to fix. With automation provided by Parasoft SOAtest’s Smart API Test Generator, API tests are much easier to access and can significantly reduce the time associated with creating meaningful Test scenarios.