I'm trying to write a project using test-first development. I've been basically 
following the process from "Test-Driven Web Development with Python" (excellent 
book, by the way) but I'm writing a command line application rather than a web 
app, so I'm having to modify some bits as I go along. Notably I am *not* using 
the django test runner.

I have my functional tests in a file in my project root at the moment - 
functional_tests.py. But now I need to start writing some unit tests and I need 
to refactor my tests into a more manageable structure.

If I create a "tests" directory with an __init__.py and "unit" and "functional" 
subdirectories, each with __init__.py and test_XXX.py files in them, then 
"python -m unittest" works (as in, it discovers my tests fine). But if I just 
want to run my unit tests, or just my functional tests, I can't seem to get the 
command line right to do that - I either get all the tests run, or none.

What's the best way of structuring my projects so that:

1. I can run all the tests easily on demand.
2. I can run just the functional or unit tests when needed.
3. I can run individual tests (or maybe just individual test modules, I don't 
have so many tests yet that I know how detailed I'll need to get!) without too 
much messing (and certainly without changing any source files!)

I know that tools like py.test or nose can probably do this sort of thing. But 
I don't really want to add a new testing tool to the list of things I have to 
learn for this project (I'm already using it to learn SQLAlchemy and colander, 
as well as test-driven development, so I have enough on my plate already!)

I've looked around on the web for information - there's a lot available on 
writing the tests themselves, but surprisingly little on how to structure a 
project for easy testing (unless I've just failed miserably to find the right 
search terms :-))

Thanks for any help,
Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to