Testing at MACH Speed: A is for APIs

Attack of the APIs!

So Application Programming Interfaces – APIs – don’t really attack. But as the A in the MACH framework, they are essential as they allow the microservices (described in our last post) to communicate and exchange data in real time. This makes testing APIs critical because an issue with an API can have a significant and far-reaching impact on the customer as well as the rest of the system.

One quick aside – some teams will call their APIs “Endpoints,” but for this blog series, I’m sticking with API/APIs.

APIs work hand-in-hand with microservices using the ‘Design by Contract’ development pattern, a.k.a. the Contract. That is, we’re going to have a contract for each API that will tell us:

• The inputs (both acceptable and unacceptable)
• What message(s) will be returned (for both acceptable and unacceptable inputs)
  • Error messages that are to be expected
  • Confirmation messages that are to be expected
  • If these messages will be visible to the UI
• Preconditions before they handle the data
• Postconditions after they handle the data

Once the developers have settled on the contracts between the APIs, they will need to let QA know how these are structured so we can build our tests. We’ll come back to the Contracts in a moment. But before we go into the best practices for testing APIs, we need to make a couple of decisions around tools.

Most APIs will use REST calls such as QUERY, GET, HEAD, POST, and PUT that can be tested manually using any web browser’s developer tools. However, just using web browser-based developer tools will limit you to just individual manual testing that won’t be able to be automated or scaled.

Here is where the tool conversation starts. There are several great API-only testing tools like Postman, ReadyAPI (formally SoapUI), and Insomnia that allow you to both manually and automatically test APIs. These tools can even be integrated into your team’s continuous development pipeline. There are also automation tool suites that offer API testing as part of their other integrated automation test tools, such as Katalon and SauceLabs. Finally, there is performance testing (which often gets confused with automation testing) with tools like JMeter and Gatling.

The key to knowing which tool(s) will work best is to think the following questions through with your team:

• How often do we see the APIs contracts changing?
  • If you have a lot of change, like at the start of development, stick with web browser-based developer’s tools until the contracts are solidified. Then move to a tool like Postman, ReadyAPI, or Insomnia.
• Do we plan on performance testing the APIs individually, or do we want to performance test the system as a whole?
  • If individually – you can use Postman, Insomnia and ReadyAPI
  • As a system – JMeter and Gatling will be the tools I’d recommend
• Do we want to monitor the APIs in production to ensure they are performing as expected?
  • Both types of tools offer production performance monitoring, but it is easier to set up monitors for individual APIs vs. one that is system-wide

When building out our API tests in a MACH framework, we want to ensure the APIs are reliable, efficient, and secure.

It is important that we have a test that covers each section of the contract, and we want to cover a mixture of both positive and negative tests. In addition, be sure that there are tests that cover Field Validation rule(s) and Error / Time Out messages since these are critical to a well-performing API.

We test the most scenarios with the fewest number of tests. One goal is to take the same API tests that you use during development testing and use them during both integration and End-to-End testing.

Security is just as it sounds; we need to be sure that our APIs can only be accessed by authorized, secured requests. Sadly, SQL injection attacks are still risks that have to be considered. It’s worth checking your inputs to ensure that they cannot be used to inject malicious queries via your APIs. Let’s not get into the world of headaches that a Denial of Service attack can have if your API is publicly exposed when it shouldn’t be…so be sure your APIs are protected by authentication if they are not meant for public use.

Remember that at some point, you will need to test the APIs as a flow with other APIs. Often as an initial integration test, I recommend building one order that has every combination of item types, services, and shipping methods the system needs to support and process that order to see if we have any failures. This is often faster than trying to build individual orders to test each on their own.

Testing APIs used in the MACH framework is essential to ensure that they are reliable, efficient, and secure. By following the best practices above, you can certify that your APIs are able to handle the demands of a busy ecommerce environment.

Speaking of a busy ecommerce environment, join me next time as we talk about the Cloud – the C in the MACH framework!