Test Your Service APIs through Test Automation

(Cover photo by Florian Olivo on Unsplash)

You need to test your service APIs. You may expand your application into a service API. Or, you may consume someone else’s service API. How do you guarantee the behavior of your own service API? And how do you ensure that your application which depends on a third-party service API? Whether you develop your own service APIs or depend on others, learn to test your service APIs.

This imperative lies at the heart of the Test Automation University course, “Exploring Service APIs through Test Automation”, with instructor Amber Race (Twitter: @ambertests). We’re offering courses like this to help engineers like yourself think about, and improve, the quality of your services through test automation.

Introduction slide to Amber Race’s course

A Student in Test Automation University

In taking this course as a student, I realized that there are two kinds of service API testers. One tester works with the developers to ensure that the service API code is exercised against the existing specification as well as the API design. The other tester consumes the service API and may choose to test the API in advance of using it in a production application. When I shared this observation with Amber, she reminded me that you, as a service API consumer, are most likely to depend on the service API provider to have tested the API; still, the lessons you learn in this course can help you evaluate a vendor prior to accessing their API.

Whether you are a service API producer or a service API consumer, you can take advantage of a structured approach to design tests that allow you to explore the behavior and limits of an API.  The key to successful service API testing is to imagine prospective failure modes in advance and test against those across a structured approach to considering proper and improper API behavior.

POISED to test your APIs

The POISED model for testing APIs

Amber Race does a great job with this course. If you are new to testing service APIs, this course can help you understand the concepts and tools available.  Amber starts by defining and exploring service APIs. She also spends time describing the POISED model for building API tests:

• Parameters – the range of parameters passed to the API
• Outputs – validating proper outputs for both good and bad parameters
• Interoperability – Ensuring consistency with other service APIs and other calls
• Security – Ensuring access and authorization maintained for API calls
• Errors – Report errors clearly and accurately
• Data – Handle data structures and real data properly and with the appropriate timing

This structure gives an experienced QA engineer a range of tests to consider applying to the service API.

Hands-On With Postman

Elements of the Postman screen from the documentation pages on getpostman.com

Another great thing about this course is the tools. Amber uses Postman, a tool you can use to test your service APIs both in development and production. Postman provides for the development of individual tests of each service API you wish to test. You can use built-in scripting and integration with data sources of your choice to turn one-at-a-time tests into a test suite with the power to test across all elements of the POISED model.

I inferred from the course that Amber had a lot of experience in testing, and that helped her imagine potential failure modes for each element of the POISED model. Think about how an API handles parameters. Sometimes the code for checking a passed parameter can be overly restrictive, resulting in an error when it is passed valid data. Sometimes the code does not check data for type or validity, resulting in unexpected behavior.

Screenshot of my Postman instance while I was learning to test service APIs.

Let’s take the example of a parameter that is supposed to be a person’s name. Is the API so restrictive that it only accepts Latin letters? What about punctuation, like hyphenated names, or suffixes like, “, Jr.”?  How about names with a space separator, like Mary Claire, or names that include numbers? What about names in non-Latin languages, such as Arabic or Chinese? Will the API field accept any Unicode text? What happens when the Unicode is explicitly articulated, like &#8211? How about a null field? What happens when the passed data is actually a URL?

The more experienced you are as a tester, the more you can consider the range of potential behaviors that an API may exhibit and the test modes you will want to apply.

For this reason, you’ll find that the POISED model helps you frame the behaviors you can test against when building tests for your service API.

Class Exercises Testing Your Service APIs

The course offers plenty of examples of how Postman can help you test your service APIs. For example:

1. Parameters – check both valid and invalid parameters. Mishandling of valid input will result in user frustration.  Mishandling of invalid input can lead to a host of problems, from security breaches to data corruption.
2. Outputs – ensure that the output for each service API conforms to your specification. Know how the output behaves with unexpected inputs. Check response codes versus expected responses for both successful results and improper parameters. Will the API consumer know what happened and why?
3. Interoperability – test both function and performance implications of APIs to know how they behave with others. Say you develop a two API retail application. The first API takes a product specification and returns a list of matching UPC codes. The second API takes a location, radius, and a UPC list, and returns a list of retailers in the radius carrying those products. Testing tells you whether you can pass the retailer list API a batch of UPC codes or if the retailer API behaves best with one UPC at a time.
4. Security – know how the API treats active, expired, and invalid credentials. Apply potential vulnerabilities – such as passing parameters that are actually cross-site scripts, and observe results.
5. Errors – apply known errors and validate that the API reports errors clearly and unambiguously.
6. Data – verify the API behavior handles data structures correctly. Compare parameters entered, such as API parameters, as measured data, such as dates and times.  For permanent records, validate that data does not change over time. For databases, compare API behavior for different functions (search, sort, etc) versus database size.

Takeaways

Amber’s course is a great start to understanding API testing. Postman lets you build lots of automation. Postman also has an instance called Newman that works with a command-line interface. While the course does not cover all the details, the course describes how you can use Newman to integrate API testing into your CI-CD solution.

My big takeaway is that experience is the best teacher. The more failure modes you have encountered as a QA engineer, the more failure modes you can consider in your API tests.

Whether you are new to service API testing or an experienced service API tester, this is a great course, as you will end up with tools and approaches to help you test successfully.

As with all courses in TAU, students who complete the course successfully get a certificate of completion. Here is mine:

The next course I plan to take also sounds interesting: Web Element Locator Strategies with instructor Andrew Knight.

Next Steps

Check out this webinar featuring Amber Race about running tests in production.

Find out more about Test Automation University in this overview with Angie Jones.

If you are new to Applitools, check out this overview of Applitools and what we do.

There are plenty of other great courses on Test Automation University.  If you haven’t enrolled in Test Automation University yet, It’s easy. Sign up at testautomationu.applitools.com.