Helma Logo
main list history

Version 4 by hannes on 05. September 2008, 16:25

Version 3 by hannes on 02. September 2008, 12:57

3i'd like to announce a unit testing module for helma-ng which i justjust committed into the *sandbox|http://dev.helma.org/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*), in that:
4committed into the *sandbox|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng*. i chose a different approach compared to
5jala.Test (inspired by *python's unittest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng*), in that:
11instead of creating test methods in a file and declaring them in anan "tests to be run"-array, a test file for unittest-ng now looks like this:
12"tests to be run"-array, a test file for unittest-ng now looks like
13this:
20so basically a unit test consists of any number of TestCase instances, and all test methods are properties of these instances (including
21special setUp() and all tearDown() methods). mind that the test runner will only execute those testcase methods are properties of these instances (includingwhose name starts with "test", all others will be ignored.
22special setUp() and tearDown() methods). mind that the test runner will
23only execute those testcase methods whose name starts with "test", all
24others will be ignored.
34# import the test module itself (eg. importModule("mytestmodule")) and a) either call mytestmodule.run(), which will (as in 1) above) run allall 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.
35test case methods or the test suite, or b) call mytestmodule.testCase.run("testMyTestMethod"), which only
36executes the method passed as argument, including setUp and tearDown if
37defined. this might be convenient when writing tests.
36unittest-ng contains the same assertion methods as jala.Test, and theythey too appear as global ones in the test module (have a look at the *selftest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng/selftest.js* for details).
37too appear as global ones in the test module (have a look at the
38*selftest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng/selftest.js* for details).
42what i'm planning next is to create mock objects for request andand response, allowing to simulate http requests within a unittest, which
43responseshould make testing web applications alot easier (without the need touse helma.Http, allowing to simulate http requests within a unittest, whichas in jala.Test).
44should make testing web applications alot easier (without the need to
45use helma.Http, as in jala.Test).

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

4committed 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
5*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:
6jala.Test (inspired by *python's unittest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng
7*), in that:
6
10* setUp and tearDown methods are called before resp. after each testtest method
11method
49selftest module [3] *selftest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng/selftest.js* for details).
59

Version 1 by hannes on 02. September 2008, 12:53

1From *Robert's announcement on the mailing list|http://helma.org/pipermail/helma-ng/2008-June/000112.html*:
2
3i'd like to announce a unit testing module for helma-ng which i just
4committed into the *sandbox|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng
5*. i chose a different approach compared to
6jala.Test (inspired by *python's unittest module|http://dev.helma.org/trac/helma/browser/sandbox/unittest-ng
7*), in that:
8
9
10* it is shell-based
11* it supports both test cases and suites
12* it supports multiple test cases in a single .js file, each containing an arbitrary number of test methods
13* setUp and tearDown methods are called before resp. after each test
14method
15
16The structure of a unit test is also different compared to jala.Test:
17instead of creating test methods in a file and declaring them in an
18"tests to be run"-array, a test file for unittest-ng now looks like
19this:
20
21  importFromModule("unittest", "*");
22  
23  var testCase = new TestCase("myTestCase");
24  testCase.testMyTestMethod = function() {
25    [...]
26  };
27
28so basically a unit test consists of any number of TestCase instances,
29and all test methods are properties of these instances (including
30special setUp() and tearDown() methods). mind that the test runner will
31only execute those testcase methods whose name starts with "test", all
32others will be ignored.
33
34test suites look quite similar:
35
36  importFromModule("unittest", "*");
37  
38  var testSuite = new TestSuite("myTestSuite");
39  testSuite.addTest("firstmodule");
40  testSuite.addTest("secondmodule");
41  [...]
42
43A test case or suite can be run in two different ways:
44
45# 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
46# import the test module itself (eg. importModule("mytestmodule")) and a) either call mytestmodule.run(), which will (as in 1) above) run all
47test case methods or the test suite, or b) call mytestmodule.testCase.run("testMyTestMethod"), which only
48executes the method passed as argument, including setUp and tearDown if
49defined. this might be convenient when writing tests.
50
51unittest-ng contains the same assertion methods as jala.Test, and they
52too appear as global ones in the test module (have a look at the
53selftest module [3] for details).
54
55the big other differences to jala.Test are:
56* the order of execution of test methods is currently not guaranteed, so each test method should be completely self-contained
57* 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.
58
59what i'm planning next is to create mock objects for request and
60response, allowing to simulate http requests within a unittest, which
61should make testing web applications alot easier (without the need to
62use helma.Http, as in jala.Test).
63