This AI is still in early stages of development.
Module Lifecycle Object
- Aubergine
Syntax
// lifecycle object passed in to Test.module()... Test.module(modulePath[, lifecycle]);
Lifecycle Properties
The second parameter, lifecycle, which is optional, can be passed an object containing one or more of the following properties...
Property | Type | Mandatory | Notes | API Version |
---|---|---|---|---|
url | String | Optionally specify a URL to associate with tests in the module. Usually this will be a URL to documentation for the features being tested. It will sometimes be output in test results, but useful to specify regardless as people reading your test script will know where to go for more information on the features being tested. | 1.1 | |
setup | Function | Optionally run a function before each unit test in the module. The function has a single parameter that specifies the state of the test prior to running the unit test (see Notes below for list of possible values). | 1.1 | |
teardown | Function | Optionally run a function after each unit test in the module. The function has a single parameter that specifies the state of the test after running the unit test and processing it's end event (see Notes below for list of possible values). | 1.1 | |
moduleData | Variant | Optionally specify some data (an object, array, primitive, function, etc) to pass in to the setup and teardown functions, and also all Unit Tests that belong to the module. The data will be available via a moduleData variable in the startup and teardown functions and any unit tests associated with the module. | 1.1 |
Notes for Setup and Teardown functions
The scope of unit test functions is manipulated before a test runs, so you cannot reference variables defined in the function's scope chain (closures will not work either).
If you want to reference variables external to the functions, pass them in via the moduleData property in the lifecycle object.
Like the Unit Tests function, the setup and teardown functions are manipulated before they run to assume the scope of the unit test instance they are being triggered by. You can access the same variables and properties as listed on the Unit Tests documentation page (eg. _global, testData, moduleData, modulePath, etc).
You can also access all Test Assertions and Test Signals from within the setup and teardown functions.
If an error occurs in a setup or teardown function, it will be recorded as an error message in the unit test that invoked the function, also causing that test to fail.
The functions have a single 'state' parameter which can be one of the following values (applicability to function shown in the setup/teardown columns):
State | setup | teardown | Notes | API Version |
---|---|---|---|---|
Test.UNIT_PENDING | In setup function, indicates the unit test / asynchronous session has not yet started. By the time the teardown function gets called, the state will be either Test.UNIT_RUNNING, Test.UNIT_SUCCESS or Test.UNIT_FAILED. | 1.1 | ||
Test.UNIT_RUNNING | In setup function, indicates current test is appending to an existing asynchronous session. In teardown function, indicates the current test did not complete the current asynchronous session. See Test.ASYNCH( ) and Test.APPEND( ) for more details. | 1.1 | ||
Test.UNIT_TIMEOUT | In setup function, indicates that the asynchronous session has timed-out. By the time the teardown function gets called, the state will have resolved to either Test.UNIT_SUCCESS or Test.UNIT_FAILED. | 1.1 | ||
Test.UNIT_SUCCESS | In teardown function, indicates the test has passed. If an asynchronous session was active, it has now finished. | 1.1 | ||
Test.UNIT_FAILED | In teardown function, indicates the test has failed. If an asynchronous session was active, it has now finished. | 1.1 |
Examples
The setup function gets called prior to each invocation of a unit test, and also when an asynchronous session times out.
Test.module("Tests/Test.js/Signals", { setup: function(state) { // make all tests in the module require the // previous test to have passed REQUIRE("^"); } }); Test("will fail", Test.ANY( ), function() { ABORT( ); // fail here }); // the setup() function will fail the requirement // and prevent this test from even running Test("will fail", Test.ANY( ), function() { ok( true, "Will this fail?" ); });
The teardown function gets called after each invocation of a unit test, and also after an asynchronous session times out.
// teardown function called immediately after each unit // test in the module, including Test.APPEND( ) mode Test.module("Tests/Test.js/Signals", { teardown: function(state) { // add a comment based on test state switch (state) { case Test.TEST_RUNNING: { comment( "This could take a while" ); break; } case Test.TEST_SUCCESS: { comment( "AWSOME WIN!" ); break; } case Test.TEST_FAILED: { comment( "EPIC FAIL!" ); break; } // Note: Test.UNIT_TIMEOUT will never // reach teardown as test will have // resolved to Test.UNIT_SUCCESS or // Test.UNIT_FAILED by this point. } } }); Test("will fail", Test.ANY( ), function() { ABORT( ); // fail here }); // will have "EPIC FAIL!" comment added to it's results Test("will timeout", Test.ASYNCH( 10 ), function() { // will pass after }); // Gets "This could take a while" comment added first, // then after timeout an "AWESOME WIN!" comment
If you want to ensure setup / teardown functions only process once per test session (which can have multiple units in the case of an asynchronous test with appends), use strict equality checks to determine the relevant states as shown below...
Test.module("Tests/Test.js/Signals", { setup: function(state) { if (state === Test.UNIT_PENDING) { // stuff to do only at start of test session } else { // state === Test.UNIT_RUNNING or Test.UNIT_TIMEOUT // stuff to if appending / timeout } } teardown: function(state) { if (state === Test.UNIT_SUCCESS || state === Test.UNIT_FAILED) { // stuff to do only at end of test session } else { // state === Test.UNIT_RUNNING // stuff to do if still running (waiting for appends / timeout) } } });
Contents
Jump to:
Test API
Topics:
- Test() — Define a unit test and it's configuration...
- Test Modules — A test module groups one or more unit tests and provides additional lifecycle settings for those tests...
- Test.module() — Allows multiple tests to be grouped together in to modules...
- Module Lifecycle Object — Configure the lifecycle of tests in the module...
- Test Modes — Defines the mode in which a unit test is run...
- Test.ANY( ) — The most basic unit test mode...
- Test.EXPECT( ) — Causes the test to fail if it does not generate the specified number of results...
- Test.ASYNCH( ) — Causes a test to keep running until it either passes, fails or times-out...
- Test.APPEND( ) — Appends results to a specific asynchronous test session...
- Unit Tests — The unit test function, responsible for performing one or more Test Assertions...
- Test Assertions — Assertions are used to perform various tests and annotations within a unit test...
- comment( ) — Adds a comment to the test results...
- ok( ) — A simple state checking assertion...
- hasNative( ) — Assert presence of a native property on the global object...
- hasFunction( ) — Check if a context has a function property, optionally with specified number of formal parameters...
- equal( ) — A basic equality checking assertion...
- notEqual( ) — A basic inequality checking assertion...
- strictEqual( ) — A strict equality checking assertion...
- notStrictEqual( ) — A strict inequality checking assertion...
- deepEqual( ) — A deep equality checking assertion...
- notDeepEqual( ) — A deep inequality checking assertion...
- 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...
- Test Events — Events defined by Test API...
- Test Results — After testing is finished, output results...
- Test API - Dev Notes — Developer notes for this API...
- Test API - possible future direction — Rough ideas for future development...