Project Hurricane is a web-based service for creating and scheduling load tests of HTTP based APIs. 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 into your scripts that get replaced when the test run. This makes it easy to create tests that can be run in 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 provided by 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