helma.unittest

From Robert's announcement on the mailing list:

i'd like to announce a unit testing module for helma-ng which i just committed into the sandbox. i chose a different approach compared to jala.Test (inspired by python's unittest module), in that:

• it is shell-based
• it supports both test cases and suites
• it supports multiple test cases in a single .js file, each containing an arbitrary number of test methods
• setUp and tearDown methods are called before resp. after each test method

The structure of a unit test is also different compared to jala.Test:
instead of creating test methods in a file and declaring them in an "tests to be run"-array, a test file for unittest-ng now looks like this:

  importFromModule("unittest", "*");
  
  var testCase = new TestCase("myTestCase");
  testCase.testMyTestMethod = function() {
    [...]
  };

so basically a unit test consists of any number of TestCase instances, and all test methods are properties of these instances (including
special setUp() and tearDown() methods). mind that the test runner will only execute those testcase methods whose name starts with "test", all others will be ignored.

test suites look quite similar:

  importFromModule("unittest", "*");
  
  var testSuite = new TestSuite("myTestSuite");
  testSuite.addTest("firstmodule");
  testSuite.addTest("secondmodule");
  [...]

A test case or suite can be run in two different ways:

1. import the module "unittest" in the shell and execute unittest.run("mytestmodule") - this will run all test cases and suites defined in the specified module
2. import the test module itself (eg. importModule("mytestmodule")) and a) either call mytestmodule.run(), which will (as in 1) above) run all test case methods or the test suite, or b) call mytestmodule.testCase.run("testMyTestMethod"), which only executes the method passed as argument, including setUp and tearDown if defined. this might be convenient when writing tests.

unittest-ng contains the same assertion methods as jala.Test, and they too appear as global ones in the test module (have a look at the selftest module for details).

• the order of execution of test methods is currently not guaranteed, so each test method should be completely self-contained
• running tests can possibly leave traces behind (eg. when defining properties in the global object within a test module), so make use of tearDown to clean up.

what i'm planning next is to create mock objects for request and response, allowing to simulate http requests within a unittest, which
should make testing web applications alot easier (without the need touse helma.Http, as in jala.Test).