Tip

Onus for third-party APIs is on enterprise developers

Testing integration points between one organization's application program interface and another's third-party API generates a minefield of possible issues. Having developers and quality assurance professionals work closely creates the best chance of successfully flushing out integration defects because both skill sets are required.

The first order of business is for

Requires Free Membership to View

quality assurance (QA) to understand what type of application program interface (API) or service is being used, and why. There are vast complexities in how APIs function based on type. In basic terms, an API creates the rules that allow two or more applications to communicate with each other. Different types of applications will require different types of interfaces to make them interoperate effectively.

Before it decides to integrate with any particular third-party API, the development team should already be planning to take responsibility for building a test suite around that API. Don't rely on unknown or unproven third-party testing practices. If it's important for the way the API functions, tests need to be created for it. The development team can't assume that the features they care about are being thoroughly tested by the original API developers.

Granted, it may be feasible to ask the third-party API provider if they will supply release notes and if there are testing hooks or any logging output useful to you. If they don't know or don't respond, that won't bode well in the business decision whether or not to use the API. The main line of defense is to develop a test suite for the API as required for your uses.

Develop a wrapper

According to Noel Rappin, senior consultant at Chicago-based Obtiva, the most effective method of isolating a third-party API for testing is to create a wrapper around it. This allows developers to add logging code and make issues easier to isolate and debug. A wrapper also adds control around the third-party API so integration unit tests can be coded and testing doesn't have to rely solely on verifying the API behavior manually. After all, testers won't know when a third-party API changes, which means it can break the system at any time.

Before it decides to integrate with any particular third-party API, the development team should already be planning to take responsibility for building a test suite around that API.

A well-designed wrapper will abstract away the differences between an organization's application and the third-party API it integrates with. It will also allow the development team to manage API interactions along with the rest of their code logic. Wrappers are also useful when testing requires mocking or stubbing a Web service. Developers can mock at the wrapper level rather than the Web service level.

It is imperative that developers verify and test the wrapper both individually and as part of the integrated automated unit tests created. That way, third-party API change issues are detected by error messages before code is deployed or users experience a negative event.

Create automated unit tests

The best way to test third-party API calls and functions is within the code itself by using automated unit tests. Automated unit tests are designed to execute each time new code is checked into a release build. In order for team members to develop these tests effectively, consider creating learning tests for each feature of the outsourced API used.

Learning tests are integrated tests written against the public contract of the API. In this way, integrated unit tests immediately fail if the API has changed and affected the code. Additionally, the development team learns how the API functions.

Additional depth is added to unit tests by using the QA resource to understand how the APIs function and by mapping failure points. Tests are added for each failure point. If feasible, the QA tester in charge of source code is then trained to step through unit tests before each deployment that verify how the API is functioning . This tester also kicks off automated execution and promptly reviews the results.

Monitor third-party APIs by monitoring automated units' test results. If the team is using multiple third-party APIs, they should create a comprehensive automated regression suite via unit testing. Monitoring outsourced APIs through unit testing ensures issues are caught before they are experienced and reported by users.

Final pass with a manual test

It's tempting to bypass the manual test. However, viewing the behavior of the system together with native and third-party APIs is essential to verifying that the system functions as expected. For example, what if there's a field missing because it's not in the documentation? The unit tests pass, but when a user accesses the code, it fails. Manual testing should catch this type of flaw.

It takes only a small amount of time for development or QA to run a manual test and verify the results. In this way, the customer is not affected by unknown changes to embedded third-party APIs and the system works as users expect.

This was first published in July 2014

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.