Speed the development of your automated REST API tests across microservices and end-to-end workflows.

Overview

Ride is a service-agnostic, modular, extensible Java REST API automation framework. It speeds test development by:

• Abstracting repetitive code
• Standardizing service-specific calls
• Integrating testing across microservices and workflows
• Auto Generating json payloads from schema
• Auto-Fuzzing payloads defined by arbitrary json schemas
• Running Perfomance tests against entire workflows without re-writing your test code

Current

Ride

2.0.0

Getting Started

While Ride can be used as is, it is more powerful when extended for your specific services. Extending it consists of three steps:

• Providing config information, in the form of environment property files and payload schemas
• Creating extensions from the core API Controller and ModelObject, which consume the config info you provide
• Writing tests using the configured extension(s)

To begin to building your test extention, create a standard java project in the IDE/Build Tool of choice (the samples shown here are in Eclipse using Maven).

Configuration

With your base extension project created, provide Ride with the information discussed above on how to talk to your service:

• Environment config files (*.properties) to target your service
• JSON schemas which describe the payloads sent to the service

These should be placed in folders named as shown below in your project main resources (you may want to have a centralized, shareable resources jar - see samples):

Target Environments

Ride is designed so that multiple environments can be indicated, and multiple services for each environment can be defined. In the example below, 2 services are defined for localhost.properties (how to target them is discussed a bit further down). They will be consumed by your extension:

The advantage here is that if you have multiple services (even multiple extensions), you can run complete inter-service (end-to-end) flows targeting all service (using their respective test extensions) in one test.

Payload Definitions

Your service payloads are defined by standard json schema, and are organized into the services they target by folders as shown above.

Extending

Once you have your schemas and environment properties files setup, you can begin to create your extension. This is done by extending the ModelObject and extending the RestApiController

An examination of the pom files in those two sample projects will given you an idea of the dependencies you will need to identify in order to build and use your extension. You build your extension as you would any java project. Below is an example using Maven

Writing Tests

Once you have created and built your extension, you can begin using is tests which abstract away a significant portion repetitive code, as is shown below (the annotation is TestNG standard, built into Ride):

  @Test(groups = {"smoke", "acceptance"})
  public void testAuthenticatedCalltoServer() {
    String itemName = UUID.randomUUID().toString();

    // Create object
    SampleServiceObject1 testObject = new SampleServiceObject1(itemName, false);
    
    // Send object data to service
    SampleServiceController.createOrUpdateObject(testObject.getObjectPath(), testObject,
        ExpectedResponse.CREATED_RESPONSE, true);
  }

If you don't have Maven failsafe configured, it is recommended that you append your test file names with "_IT" so that they will be run by Failsafe as opposed to maven Surefire (for example, MyBasicTest_IT.java).

Running Your Tests

When you are ready to run your tests from the command line, below are a few examples of run commands (standard maven command line syntax):

#run all against prod01 environment
mvn clean verify -Dtarget=prod01

#run specific test
mvn clean verify -Dtarget=prod01 -Dit.test="myGreatTestFile_IT.java#creationTest

#run specific test group
mvn clean verify -Dtarget=prod01 -Dgroup=smoke

Fuzzing

With a few simple lines of code, you can generate different data type and content tests against the payload schema to see if your service handles each correctly. Ride internally maintains arrays of non-strings, SQL injection strings, No SQL injection strings, and localized strings to test against the definitions in your schema. The Fuzzer walks the entire hierarchy of any arbitrary schema and tests each node in isolation (sample code):

@Factory
  public Object[] fuzzObjectMetadata_IT() throws Exception {
    String itemName = UUID.randomUUID().toString();
    SampleServiceObject1 object1 = new SampleServiceObject1(itemName, false);
    return new Object[] {new MetadataFuzzer(Service.SAMPLE_SERVICE.toString(), object1)};
  }

Performance Testing

Part of the power of Ride is that once you have your extension written, you can use it for fuzzing (as shown above), but also for performance testing. The performance library in Ride is based on Gatling, so while there is a bit of setup, and a bit of a shift in syntax to scala, you are still able to setup tests that measure performance for full flows of data withough having to rewrite what you've already created in your extension - sample Ride performance test.

Additional Documentation

There are a number of supporting informational documents in this repo which will help you utilize and perhaps contribute to Ride.

• Architecture (former main readme)
• Quick Start
• Usage
• Using Authentication