eliben wrote:
Hello,
At the moment, I place all the code of my project in a src/ directory,
and all the tests in a sibling tests/ directory, so for instance a
sample project can look like this:
doc/
...
src/
play.py
write.py
tests/
test_play.py
test_write.py
While this works fine, I have a couple of questions:
1) To make this scheme work, each test file begins with
sys.path.insert(0, '../src'). I wonder if there's a better way to do
this, because this one doesn't look flexible (what if the code gets
complex and I subdivide it to directories in src/...)
You would then make packages and access your modules within tests using
Python dot notation. In this case though, you'll probably want to rename
src into a more specific package name.
If you don't want to mess up with the python path within each test file,
you may want to make the package your testing available globally for
import. A quick way to do it is by setting the PYTHONPATH environment
variable. This can quickly become tedious if you work on multiple
packages. Another solution would be to link your packages within
site-packages, which is (hopefully ;) already in your path. The ultimate
solution to do that is to make you package an egg and install it in
development mode (ie: python setup.py develop). This is made very easy
by Paste Script and its basic_package template (paster create -t
basic_package), see http://pythonpaste.org/script/developer.html for
more on that. A good thing with having your package in your Python path
is that you can fire a interactive interpreter from anywhere and play
with your API.
2) Is there a better way to organize this ? Preferably I'm looking for
a single method that is applicable to:
* Complete stand-alone applications with a single entry-point
* Libraries with several files that should be imported by the users
Does it actually make a difference when it comes to unit testing? Even
for standalone apps you'll want to unit test each module composing the
app, won't you ? ;-)
--
http://mail.python.org/mailman/listinfo/python-list
