I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

-- including mobile or cloud-based -- to access Web services seamlessly. However, it's critical to perform automated API testing to ensure the API provides not only the advertised functionality but also security, reliability and scalability for consumers.

The API layer is a prime candidate for automated testing. However, too often teams start by automating at the GUI level, rather than focusing on the API or unit test level, where there's a much better return on automation investment. In this article, I'll look at automated API testing, the middle layer of the test automation pyramid, and explain the benefits and importance of automated testing at this level.

What is an API?

An API is a software function or service that is accessible programmatically rather than with a user interface. By exposing APIs to programmers that specify expected inputs, outputs and functions that will be performed, API consumers (also programmers) are then able to write their own code that will integrate with the API. This allows programmers to share functions or services, taking advantage of reusability.

Web APIs are for either a Web server or Web browser. Server-side Web APIs, sometimes known as Web services, are defined with a response-request message system, typically written using JSON or XML. The Web services may be SOAP-based, or they may use the increasingly common REST architecture style, conforming to constraints that will lead to a high performing and maintainable architecture.

Automated API testing

Because APIs lack a GUI, they may be a challenge for manual testers used to having an application to test. However, test tools are available that allow the tester to access the API, send requests and ensure the correct responses are returned in the right format. Amy Reichert reminds us that testers must not only test for functionality, but for security and connectivity when they're testing an API.

API tests also are prime candidates for automation because the tests will be programmable. And because they are able to bypass the GUI layer, the tests will be much faster and more reliable than automated GUI tests. Creating automated API testing will allow you to test all the functional paths without the complications introduced when going through a GUI. Automated API testing also will be fast enough to allow the tests to be part of a continuous integration build. In this way, the APIs will be regression tested with every new build. It's crucial that the integrity of the API specification is maintained so that all consumers of the API can depend on its quality.

Another reason to focus the automated tests at the API level rather than the GUI level is that the GUI changes frequently, which means regular maintenance is required for GUI-level automated tests. The majority of the edge cases testing for functionality should be done at the API or unit level, reserving only the system level end-to-end testing, usability, and exploratory testing to be tested at the GUI level.

Tools for automated API testing

Although developers often are responsible for automated unit testing (white box tests where the code paths must be understood) usually someone in a QA role is responsible for testing APIs. These will be black box tests. In other words, automated API testing should be approached as an API consumer who doesn't have visibility into the code, but only knows the defined interface. That being said, often some programming or scripting experience is a big advantage for the API tester.

A variety of tools provide testers the means to thoroughly test at the API level without development experience, though, again, some coding knowledge will be a benefit. In a recent LinkedIn discussion, a user asked for opinions and preferences about SoapUI versus JMeter as free tools to write and execute REST API tests.

Easing API testing constraints

Although there were several votes and opinions, there didn't seem to be a clear preference. The most detailed answer describing some of the differences came from Scott Muller who said his company has dropped the REST into the plug-in and parsed the response and written custom samplers. Custom samplers gave them flexibility if the APIs changed and were easier for QA testers with little programming background to use. "SoapUI takes a little more to come up to speed, but has its advantages, such as access to Soap if all of your interfaces are not converted to REST," he wrote in his post. "It also has nice reporting." His final thought: Don't forget to version your tests if your wsdl or REST change. Several responses suggested other tools as well, including the tool, REST-assured API as the best open source solution.

Although automated API testing may seem a challenge for testers new to API testing, a variety of tools are available that help ease the pain. Even though the temptation may be to test through a GUI, make the effort to learn how to go in at the API level for faster and more reliable automation.

3 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

"usually someone in a QA role is responsible for testing APIs" - why wouldn't the developer(s) who produced the API create and maintain the regression test? Feels like better use of limited QA resources would be to string together APIs into tests, or to actually test through the UI despite the added complexities?