Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

5 API Testing “Must Haves” for API Security, Reliability, Performance

DZone's Guide to

5 API Testing “Must Haves” for API Security, Reliability, Performance

Erika Delgado provides 5 API testing must haves for API success.

Free Resource

The Integration Zone is brought to you in partnership with Cloud Elements.  What’s below the surface of an API integration? Download The Definitive Guide to API Integrations to start building an API strategy.

Ensuring that your APIs are delivering the necessary level of security, reliability, and performance inevitably involves developing, continuously executing, and religiously maintaining a broad array of complex tests.

Here are 5 key API testing “must haves” that will help you achieve this: 

1. Intelligent Test Creation and Automated Validation

Exposing services as APIs without proper hardening is like bringing your child to a “developing” country without first obtaining the recommended immunizations. Fortunately, the tools and strategies for achieving the proper hardening are an extension of those that have proven effective for SOA testing—just as the process of administering the immunizations required for foreign travel is essentially an extension of administering the recommended domestic ones.

As the extreme exposure and misuse potential of APIs makes testing a broad range of conditions and corner cases critical, automation comes to the forefront. The creation and execution of simple automated tests with limited or manual validation might have sufficed given the internal scope of SOA, but more sophisticated and extensive automation is required to be confident that your APIs are robust enough to survive in the wild. You need a level of automation that gives you a comprehensive set of functional test cases that can be repeated in a systematic manner.

Recommended capabilities for this goal include an intuitive interface for automating complex scenarios across the messaging layer, ESBs, databases, and mainframes:

  • Defining automated test scenarios across the broad range of protocols and message types used in APIs: REST, JSON, MQ, JMS, EDI, fixed-length messages, etc.  
  • Automating rich multilayer validation across multiple endpoints involved in end-to-end test scenarios. 
  • Parameterizing test messages, validations, and configurations from data sources, values extracted from test scenarios, or variables. 
  • Defining sophisticated test flow logic without requiring scripting. 
  • Visualizing how messages and events flow through distributed architectures as tests execute.

2. Change Management for Test Assets and Environments

Continuously evolving APIs helps organizations stay a step ahead of the competition while responding to business demands. Yet, this frequent change presents significant quality risks if the automated test suite fails to keep pace with the evolving API.

A system for fast, easy, and accurate updating of test assets is critical for keeping test assets in sync with the changing API. If you can automatically assess the impact of changes to existing tests and then quickly update existing tests (or create new ones) in response to the identified change impacts, you can vastly reduce the amount of time required to ensure that your tests don’t fail due to expected changes…or overlook critical new functionality.

3. Service Virtualization for Simulated Test Environments

Service Virtualization technology creates simulated test environments that provide anytime, anywhere access to the behavior of dependent system components that are unavailable, difficult to access, or difficult to configure for development or testing. “Dependent components” might include mainframes, mobile app front-ends, databases, web services, third-party applications, or other systems that are out of your team’s direct control. Service virtualization can be used in conjunction with hardware/OS virtualization to access the environments you need to test earlier, faster, or more completely.

In the context of API testing, service virtualization can be applied in two key ways:

  • To provide access to the dependent componen behavior (e.g., from a mobile app, database, legacy system, or third-party service) that you need in order to thoroughly validate your API.  
  • To mimic the behavior of your own APIs, creating a test environment that API consumers can develop and test against without impacting your production environment—or to enable development and testing to begin before your APIs are completed.

4. Extensive Performance Testing—Ideally, with Service Virtualization

Due to the highly-exposed nature of APIs, there’s a high potential for unpredictable and often volatile traffic volumes. To determine whether your API will satisfy SLAs in the event of the erratic or surging demand that APIs commonly face, it’s essential to ramp up the scope of performance testing. You can use service virtualization (covered above) to create simulated test environments that help you test against different performance scenarios that would otherwise be difficult to create in the test environment.

For instance, you can easily set performance conditions (e.g., timing, latency, delay) to emulate peak, expected, and slow performance—perhaps to help you plan for cloud bursts or determine how the API might respond when someone is accessing it from China. You can also configure various error and failure conditions that are difficult to reproduce or replicate with real systems—for instance, if your APIs rely on Amazon Web Services, you can easily simulate a scenario where AWS is down. This ability to rapidly configure a broad range of conditions in dependent systems is essential for determining if your APIs provide reasonable responses—or at least fail gracefully—under exceptional conditions.

One final way that adopting service virtualization helps performance testing: you can “virtualize” any connections to third-party systems, reliably eliminating the risk that your stress tests might impact services you aren’t permitted (or budgeted) to barrage with test messages.

5. Extensive Security Testing—Ideally, with Service Virtualization

Considering APIs’ increased attack surface area, a multi-faceted security testing strategy is essential for ensuring that development has built the appropriate level of security into your application. This includes:

  • Executing complex authentication, encryption, and access control test scenarios. 
  • Generating a broad range of penetration attack scenarios involving parameter fuzzing, injections, large payloads, etc. 
  • Running penetration attack scenarios against your existing functional test scenarios. 
  • Monitoring the back-end during test execution in order to determine whether security is actually compromised.

In addition, if you’re adopting service virtualization (covered above) you can leverage it to take your security testing to the next level:

  • It provides rapid ways to emulate attack scenarios as well as emulate different security behaviors of dependencies. This lets you derive more value from your existing functional test scenarios (since you can run them vs. different security scenarios that would otherwise be difficult to configure and unfeasible to test against).  
  • It enables extensive security testing to be performed without a security expert. Existing test scenarios can be easily executed against a broad set of preconfigured security scenarios. 
  • It helps you isolate and zero in on your APIs response to various attack scenarios and different security behaviors of dependencies.

The State of API Integration Report provides data from the Cloud Elements platform and will help all developers navigate the recent explosion of APIs and the implications of API integrations to work more efficiently in 2017 and beyond.

Topics:
api testing ,reliability ,security ,performance ,api design

Published at DZone with permission of Erika Barron-Delgado, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}