A test module groups one or more unit tests and provides additional lifecycle settings for those tests...
Overview
When a module is defined, using Test.module(), all subsequent Unit Tests will be grouped in to that module.
Each module must be given a unique name, called a "module path". The path can be anything you want, however it's recommended to use a syntax similar to folder paths. The tests associated with APIs in this wiki use the following format: Tests/filename.ext/group/subgroup
Test.module("Tests/foo.js/Module A");
Test(...); // this test and any defined after it will go in Module A
Test.mdoule("Tests/foo.js/Module B");
Test(...); // this test and any defined after it will go in Module B
When the Test API instantiates, a default module called "Tests/" is created. If you don't define your own modules in your test scripts, they will be placed in the "Tests/" module (or the last module to be defined by prior test scripts).
Module lifecycle settings
Modules can provide additional lifecycle settings for their associated tests, including:
Start-up and tear-down functions that will be called before and after each test
Data to share between tests (module data)
A URL to associate with the tests, for example linking to documentation
similarTo( ) — A deep similarity checking assertion...
notSimilarTo( ) — A deep dissimilarity spotting assertion...
Test Signals — Signals are used to prematurely terminate Unit Tests...
REQUIRE( ) — Check whether a test or group of tests have passed. If the requirement fails, a RequireSignal will be sent which terminates the current test and marks it as failed.
ABORT( ) — Aborts the current test, marking it as failed in the process...
FINISH( ) — Terminates the test as if it had finished normally...