A new pattern for unit testing in Leo

[Edward K. Ream]

Yesterday's thread, "Does anyone use @testclass"
https://groups.google.com/forum/?fromgroups=#!topic/leo-editor/rVGRtja0m2M
is the start of a new direction for unit testing in Leo.

The straightforward test-runner script shows how to run completely standard unit tests from within Leo.  This strategy has several advantages:

1.  The unit tests can be run outside of Leo, say from the command line.

2.  The unit tests more naturally use all the capabilities of Python's unittest module (or any other unittest module).

As a result, I suspect that this will be the method of choice for some of Leo's users.  I needed this in the static-type-checking project because it would be inappropriate to force people to use Leo in that project.

Notes:

- It will be good to make the test-runner script a standard part of Leo.  It could be a command, I suppose, but it would require one or more settings.  At present, the script runs all .py files in a fixed directory as unit tests.  So the directory will have to be a setting.

- In the new scheme, the g, c and p variables are not automatically available to the unit tests.  That should not be a burden, if such access is desired.  Indeed, this kind of initing is where the unittest module excels.  The standard way would be to create a LeoTest base class, something like this::

    class LeoTest (unittest.TestCase):
        def setUp(self):
            << load the leoBridge module >>
            << define g, c & p using leoBridge >>

Now all tests that should have access to Leo can be subclasses of the LeoTest module.

- Speaking of the setUp method, I have that I need to be a bit more careful to fully init tests when using explicit unittest.TestCase classes.  I'm not entirely sure why, but using @test seems to init test cases more naturally.  As I write this, I'm not sure that this is correct, I suspect that the init logic in the @test nodes I was using was simply more hidden :-)

- The flip side of initing is that running the explicit unittest.TestCase tests seems to be *considerably* faster than when using @test.  Indeed, the test runner script does not need to scan the .leo file: the test files (in the designated test directory) are created, as usual, using @file nodes, so all the work is done when you save the .leo file.

- And speaking of saving the .leo file, you can use the standard Leo trick of moving nodes into and out of the test files to enable or disable tests.  Indeed, use a node called "disabled tests" *within* the test file that disables test classes.  This node contains just::

    if 0:
        pass # in case there are no children
        @others

So to disable a test, I simply make it a child of this node.

This post seems a bit muddled.  If you have questions about this new approach, feel free to ask.  At present, the best way to see the new scheme in action is to look at rev 133 of the static-type-checking project.

Edward