Testing APIs protects applications and reputations

When testing public APIs, test expert Amy Reichert recommends testing API functionality, endpoint security and, above all, proper connectivity.

Why test a newly developed public API or one that has veteran status? The answer is the same for testing any application software: to ensure connections and processes are functional. It is important for the reputation of a software development company to test and verify that an API can be connected to successfully, that it provides reliable security and that it functions as intended.

Testing APIs, no small task, involves more than unit test checking by developers. To protect and enhance the reputation of a company's applications, thorough tests on the API must be executed. When planning and developing tests against a public API, be sure to verify connectivity between systems. Often, verifying connectivity is tricky, but find a method that satisfies the business need. Testing connectivity is the basic premise of testing an API, but several other areas also should be considered.

Figuring out what to test

Testing teams need to determine what needs to be tested. As with any other testing, risk, priority and accessibility influence what type of testing is done on an API. At a minimum, test that the end points function and accept or transmit messages appropriately. If possible, test endpoint security as well as business logic functionality. Some testers aren't comfortable with testing endpoint security but for an initial pass it's possible to work with developers to verify that tokens and certificates cannot be circumvented easily.

Testing business logic functionality is critical. Even if the API's endpoints are secure and a connection is successfully established, it's still critical to know that the API performs the functions it's designed to do. Testing API functionality involves using a simulated customer instance that exercises all functional options. The testing team must determine if they need to create a mock customer instance or if the functionality is better tested by pilot testing or actively testing with an actual customer. The depth of testing depends on the business need and the time available for testing and development staff.

Creating API test data

The industry the application serves determines how much effort and skill is required to create test data. For example, within the healthcare software industry, it is imperative not to violate HIPAA patient information disclosure rules that result in significant government fines, not to mention the public-image damage that results from a data breach of any kind. But no matter what industry the API serves, spend the time to create sanitized or generalized data for API testing.

Sanitized data is real data that is manipulated to be valid but not recognizable or traceable to a real person. A test group can also manually alter a subset of data to use by developing personas that represent up to five customer scenarios. For example, for a data exchange API for medical records, one persona may be a patient who actively sees a primary doctor and pulmonary, cardiology and rheumatology specialists. Creating the persona includes personal data; created medical record information; and each doctor's address, phone number and patient visit information. As the patient scenario develops, testers populate the database with the minimum required data. The API can be tested using the data and verifying the proper data is returned.

Testing endpoint security

While testing the API, it's critical to test the security of the API's endpoints. Test to ensure the endpoint responds only to valid connection attempts. Testing the message security is sufficient. Many APIs use JWT tokens and certificates to ensure messages received are from authorized sources. Attempt to send unauthorized messages using an invalid token, or piggyback on a valid token to ensure the security picks it up. The API's function will determine if an outside third-party security testing service is required or if the business can do sufficient testing with existing tester and developer resources.

Testing API functionality

The test data created is used mainly for testing the API's functionality. An effective method is to create a mock API system that simulates how a real business partner would use the API. Granted, creating mock systems is time-consuming and relies on an understanding of the API's use, but it is an effective way to test API functionality. If taking the time to develop a mock application to connect and test the API's functionality is not feasible, consider using an actual business partner.

Similar to pilot testing, testing with a real business partner has advantages. The main advantage is that it is a real-world instance. The time spent in testing and development is not seen as wasted on a mock system but provides value by creating a working partner system. Another advantage of pilot API functional testing is the ability to test with two sets of test data from each API. Proving the reliability of data transfer is critical to the overall success of the API and difficult to test without a pilot system. Pilot testing also fully tests the business logic with a true customer system.

To protect existing customers and build the customer trust necessary for business growth, investing time and effort into testing a public API is worth it. Customers may be individuals as well as large and small businesses, and earning trust and respect equals business success. Testing a public API also provides an initial level of security testing and business logic verification. A software business must test to the depth necessary to ensure the quality of the API.

Next Steps

Test yourself on general API knowledge

Learn more about third-party APIs

Discover new tips on API security

Automating the API code generation process

Dig Deeper on Topics Archive