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
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/s9h07Ua1B8EJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
