Test cases

Test cases generated using Grizzly are intended to be standalone. This means that Grizzly should not be required to reproduce issues but it can be helpful.

Things to consider when attempting to run a test case without Grizzly:

• Test cases are served via a web server not loaded directly from the file system when run via Grizzly.
• By default Grizzly will open test cases in a new tab via a call to window.open(). Use --no-harness to disable this.
• Some issues are triggered during browser shutdown. Browser shutdown may not happen automatically.
• Environment variables and files (for example prefs.js files) can enable and disable features and may be required. Grizzly will generate a prefs.js file for fuzzing using PrefPicker if one is not provided.
• Some issues are timing dependent and may be unreliable due to previously mentioned or other unrelated reasons.

Loading test cases

There are a few forms of a test case that are supported. These are most relevant when using Grizzly Replay or Grizzly Reduce.

Single file

Very simple. A single file with no includes, just the content that triggers the issue.

Directory

This offers more flexibility. This is the format output by Grizzly while fuzzing.

The directory must contain a test case and a test_info.json file. The test case test.html can also include other files such as scripts/fuzz.js and media.webm for example. The test case can also include a prefs.js file which will be used automatically if detected or a custom file can be provided via --asset.

test_info.json must define the test case entry point, in this case it is test.html:

{
  "target": "test.html"
}

test.html might look something like this:

<script src='scripts/fuzz'>
<!-- more content -->
<video src='media.webm'>

The directory structure for this test case would look like this:

test/
test/scripts/fuzz.js
test/media.webm
test/prefs.js
test/test.html
test/test_info.json

Multi-test

This is a collection of directories. When fuzzing with Grizzly the option -c <#> allows the user to also include the last # of test cases in addition to the most recent. Sometimes a test case can be dependent on the previous test case (this is not ideal but is sometimes unavoidable).

The directory structure would look like this:

tests/
tests/test-0/
tests/test-1/
tests/test-2/

Each test-# entry is a directory containing a test case as previously described. The order they are replayed is oldest to newest. The age is defined in test_info.json by "timestamp" (defaults to 0 if missing).

Archive

This is a ZIP file that contains one or more directories (previously described) containing tests.