Project Hurricane is a command line tool or web-based service for creating and scheduling load tests of HTTP based APIs. This tutorial will primarily cover using the web-based service. A specific command line related section is provided at the end. The tests are defined in JSON format and provide support for many different features:

• Sequences of requests

• Random selection from possible requests

• Properties for defining the test environment

• Variables for passing data between requests

• Cookies

• Custom HTTP headers

This article will guide the reader through the process of creating their first test script and provide examples for each type of script element available for use in their test scripts.

Your First Script

When you first access the Hurricane service you will see the list of previously created test definitions.

Let’s create a new test:

1. Enter a name for your test in the Name field at the bottom of the page

2. Click the “Add Test Definition” button

Your test is created using the name you provided and you are redirected to the Edit Test Definition page.

For our first test, we’re just going to fill out the Main Script section. We’ll work with test properties and the initial and maintenance script documents later in this tutorial. Let’s start by adding some boiler plate content to the Main Script document:

{
	"headers": [],
	"steps":
	[
		{
			"name": "",
			"type": "Request",
			"method": "GET"
			"url": "",
			"body": null,
			"actions":
			[
			]
		}
	]
}

Let’s look at the top-level sections or our script:

• headers - This array allows us to add custom global headers to our script that will be included when making API requests. These will be described later in this tutorial

• steps - This array will hold the steps to take when running our test

Our first test will be very simple and make a single API request. Our boilerplate includes the body for a request step. Let’s look at the fields we’ll need to make an API request:

• name - The name of this request. This name will help us differentiate between requests as our tests become more complicated

• type - Since this is an API request the type is “Request”. Other types of steps are available and described later in this tutorial

• method - The type of HTTP request being made. Can be GET, POST, PATCH, PUT, HEAD, or DELETE

• url - The complete URL used to make the request. This includes the protocol http/https, server address, path, and any query parameters if needed

• body - The body content to send as part of the request if using POST, PATCH, or PUT. This field should be set to null or removed if using any other method

• actions - This array will hold actions to perform after the request has completed. Actions will be covered later in this tutorial

Let’s fill out the request fields with a call to a fictional API endpoint that returns “hello world!” when called:

{
	"headers": [],
	"steps":
	[
		{
			"name": "Hello World",
			"type": "Request",
			"method": "GET"
			"url": "http://localhost/hello",
			"body": null,
			"actions":
			[
			]
		}
	]
}

Once we’ve made our changes, we need to save the test definition by clicking on the “Save” button at the bottom of the page. You will be returned to the list of Test Definitions where our newly created test is now listed:

Using Test Properties

Test properties allow you to create placeholders in your scripts that get replaced when the test is run. This makes it easy to create tests that can be run against multiple environments such as Dev, QA, or Production without having to change the test definition each time or have separate definitions for each environment.

Properties vs Variables

It's important to understand the differences between properties and variables and how they are used in a test script. The first difference is where the values for properties and variables come from. Property values are provided at test scheduling time, either through specifically providing a value or using the default value defined in the test definition. Variable values are extracted from request responses while the test is running.

The second difference is related to when the placeholders are replaced. Placeholders that reference properties are replaced prior to starting the test as part of the test preparation. This means that the values cannot be changed once the test has started. Variables change dynamically and their placeholders are replaced every time a test step is executed. Variables are also scoped so that each test session has its own copy of a variable and its value. The only exception to this is that variables used in the initial and maintenance scripts are also shared with all test sessions.

Add a Test Property

Let’s add a property to our test that will hold the protocol and server information for our API request. To add a test property:

1. Click on the “Add” button in the Test Properties section of the Edit Test Definition page. This adds an empty property entry to the page

2. Provide a name for the property. For this tutorial we’ll use “ServerDomain”. The name will be used as part of the placeholder and can only contain letters, numbers, ‘-', and '_’

3. Optionally provide a default value to use for this property if a specific value isn’t given during test scheduling. For this tutorial we use our current server address: “http://localhost”

4. Once added, click the “Save” button at the bottom of the page

Reference a Test Property

To use our new test property, we need to add a reference to it in our test’s main script. A property reference has the format {{propertyname}}. In our example, we change the “url” field of our request to include a reference to the ServerDomain property:

{
	"headers": [],
	"steps":
	[
		{
			"name": "Hello World",
			"type": "Request",
			"method": "GET"
			"url": "{{ServerDomain}}/hello",
			"body": null,
			"actions":
			[
			]
		}
	]
}

Just before the test is run, the {{ServerDomain}} portion of the “url” field will be replaced with the value of our property. In this case the “url” field value would be rewritten to “http://localhost/hello”. If the test was run against a QA environment, the value might be overwritten to “http://myqaserver”. Now our test can be pointed at any number of different servers at run time without having to change the test definition itself.