Struggling with unittest discovery - how to structure my project test suite

[Paul Moore]

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