Difference between revisions of "Unit Test Quickstart"
m (New page: == Unit Test Quickstart == This page gives some simple recipes and tips for writing unit tests in the Gramps source code tree. === First, some general procedural and structural notes ===...) |
(→Unit Test Quickstart) |
||
Line 1: | Line 1: | ||
− | |||
− | |||
This page gives some simple recipes and tips for writing unit tests in the Gramps source code tree. | This page gives some simple recipes and tips for writing unit tests in the Gramps source code tree. | ||
Line 26: | Line 24: | ||
import unittest | import unittest | ||
− | from test import test_util | + | # import this test support utility before importing the module under test |
+ | from test import test_util | ||
parent_dir = test_util.path_append_parent # enables the following import | parent_dir = test_util.path_append_parent # enables the following import | ||
import MyModule | import MyModule | ||
− | this_dir = test_util.abspath | + | # look in test/test_util.py for other conveniences (and suggest more ideas) |
+ | this_dir = test_util.abspath() | ||
data_dir = test_util.make_subdir("MyModule_test_data") | data_dir = test_util.make_subdir("MyModule_test_data") | ||
+ | # unittest requires a TestCase class containing test function members | ||
+ | # optional setUp() and tearDown() functions can perform pre/post test housekeeping | ||
class Test_top(unittest.TestCase): | class Test_top(unittest.TestCase): | ||
− | + | ||
+ | def setUp(self): | ||
+ | ... | ||
+ | def tearDown(self): | ||
+ | ... | ||
+ | |||
def test_function_x(self): | def test_function_x(self): | ||
..do stuff.. | ..do stuff.. | ||
Line 41: | Line 48: | ||
..more defs for more tests, more classes for possible grouping logic.. | ..more defs for more tests, more classes for possible grouping logic.. | ||
+ | |||
+ | if __test__ == "__main__": | ||
+ | unittest.main() |
Revision as of 11:07, 6 November 2007
This page gives some simple recipes and tips for writing unit tests in the Gramps source code tree.
First, some general procedural and structural notes
- unit tests are usually created to verify correct functional behavior of a single module of source code.
- test code goes in a test subdirectory of the subject module's directory
- the test module should be named with a suffix _test so that it can be found by automatic regression test tools.
- the leading part of the test will commonly be named the same as the basename (or a variant) of the module under test, leading, for example, to the following files
src/A/B/module.py src/A/B/test/module_test.py
- the test subdirectory can contain data or helper programs as required
- the test and such supplementary elements that are persistent will be maintained as part of the source control system.
- the test module can create and delete test data during execution. Commonly this would go in a deeper subdir, named to avoid collision with other test programs.
...more to come...
Simple Code Recipes
There are only a few firm requirements to fit into the framework. Here is a simple test module that may be considered something of a template.
import unittest
# import this test support utility before importing the module under test from test import test_util parent_dir = test_util.path_append_parent # enables the following import import MyModule # look in test/test_util.py for other conveniences (and suggest more ideas) this_dir = test_util.abspath() data_dir = test_util.make_subdir("MyModule_test_data") # unittest requires a TestCase class containing test function members # optional setUp() and tearDown() functions can perform pre/post test housekeeping class Test_top(unittest.TestCase): def setUp(self): ... def tearDown(self): ...
def test_function_x(self): ..do stuff.. self.assertTrue(expression, "message to display on failure") #see other assert and fail functions in the unittest module
..more defs for more tests, more classes for possible grouping logic..
if __test__ == "__main__": unittest.main()