B
Ben Finney
Howdy all,
My practice when writing unit tests for a project is to make 'test/'
subdirectories for each directory containing modules I want to test.
project-foo/
+-- lib/
| +-- test/
+-- data/
+-- gui/
| +-- test/
+-- server/
+-- test/
This means that I need to use relative paths to import the subject
code into the unit test module.
import unittest
import sys
sys.path.append('..')
import foomodule
class Test_Foo(unittest.TestCase):
# ...
This works, so long as the foomodule is *not* in the path before the
appended '..' directory. When writing unit tests for a development
version of a package that is already installed at an older version in
the Python path, this fails: the unit tests are not importing the
development version of foomodule.
What is the common idiom here? I can conceive of several possible ways
to get around it, all of which seem hackish to some degree.
My practice when writing unit tests for a project is to make 'test/'
subdirectories for each directory containing modules I want to test.
project-foo/
+-- lib/
| +-- test/
+-- data/
+-- gui/
| +-- test/
+-- server/
+-- test/
This means that I need to use relative paths to import the subject
code into the unit test module.
import unittest
import sys
sys.path.append('..')
import foomodule
class Test_Foo(unittest.TestCase):
# ...
This works, so long as the foomodule is *not* in the path before the
appended '..' directory. When writing unit tests for a development
version of a package that is already installed at an older version in
the Python path, this fails: the unit tests are not importing the
development version of foomodule.
What is the common idiom here? I can conceive of several possible ways
to get around it, all of which seem hackish to some degree.