By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,197 Members | 909 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,197 IT Pros & Developers. It's quick & easy.

organizing python code with tests

P: n/a
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/...)

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

Perhaps this is too much to ask, but hope dies last :-)

Thanks in advance


Aug 15 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
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 ? ;-)
Aug 15 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.