Helma Logo
main list history
previous version  overview  next version

Version 2 by hannes on 02. September 2008, 12:56

From *Robert's announcement on the mailing list|http://helma.org/pipermail/helma-ng/2008-June/000112.html*:

i'd like to announce a unit testing module for helma-ng which i just
committed into the *sandbox|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ngorg/trac/helma/browser/sandbox/unittest-ng*. i chose a different approach compared to
*jala.Test (inspired by *python's unittest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng*), i chose a different approach compared toin that:
jala.Test (inspired by *python's unittest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng
*), 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 testtest 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

  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");

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

# 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
# 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 [3] *selftest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng/selftest.js* for details).

the big other differences to jala.Test are:
* 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 to
use helma.Http, as in jala.Test).