Using the mynode test harness
The mynode test harness allows developers to test mynode implementations
by writing test cases that follow a pattern.
After building mynode, change to the test directory and execute
"node driver <options>". The default is to run all tests.
Tests are organized by suites. Each suite is a directory under the
test directory. Suites typically contain the following:
create.sql: a file containing mysql commands to set up the environment
drop.sql: a file containing mysql commands to tear down the environment
SmokeTest.js: set up and verify the test environment (create tables, populate
data in tables, open a connection to the database, etc.)
ClearSmokeTest.js: tear down the test environment (drop tables, databases)
ConcurrentTest: tests to be run concurrently, using the test setup
(test schema and test data) and having no side effects (do not insert
or delete any rows in the database)
SerialTest: tests to be run serially, using the test setup. These tests
can have side effects, except for changing schema or databases that other
tests depend on. Tests that change schema should generally be in their own
test suite.
Tests are functions that are created via the ConcurrentTest or SerialTest
constructors. SerialTests and ConcurrentTests must declare a run() method.
Tests are either synchronous or asynchronous depending on whether the run
function returns immediately (synchronous) or not (asynchronous).
Most tests are asynchronous.
Synchronous tests must return true from the run function. They are
considered to pass if the errorMessages string is empty, and considered
to fail if the errorMessages string is not empty. An error may be appended
to the errorMessages string by calling the function appendErrorMessage().
A synchronous test that throws an exception is also considered to fail.
Asynchronous tests need not return anything from the run function and must
not return true. They must call the pass or fail function when they complete.
This can be done explicitly or by using one of the functions declared in Test:
fail('failure message'); // fails with the failure message as the reason
failOnError(); // fails test if the errorMessages string is not empty
fail_openSession(); // fails test if a session cannot be opened
Error messages can be appended based on conditions, by using helper
functions, e.g.
errorIfNotEqual(message, object1, object2)
Other errorIf... functions will be added as they are needed.
Test programs that implement one test export that test:
module.exports = test1;
Test programs that implement multiple tests export the array of tests:
module.exports.tests = [test1, test2];
