Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #62435 > unrolled thread

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

Started byPaul Moore <p.f.moore@gmail.com>
First post2013-12-20 06:47 -0800
Last post2013-12-20 16:48 -0500
Articles 4 — 3 participants

Back to article view | Back to comp.lang.python


Contents

  Struggling with unittest discovery - how to structure my project test suite Paul  Moore <p.f.moore@gmail.com> - 2013-12-20 06:47 -0800
    Re: Struggling with unittest discovery - how to structure my project test suite Serhiy Storchaka <storchaka@gmail.com> - 2013-12-20 19:41 +0200
      Re: Struggling with unittest discovery - how to structure my project test suite Paul  Moore <p.f.moore@gmail.com> - 2013-12-20 13:02 -0800
    Re: Struggling with unittest discovery - how to structure my project test suite Terry Reedy <tjreedy@udel.edu> - 2013-12-20 16:48 -0500

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

FromPaul Moore <p.f.moore@gmail.com>
Date2013-12-20 06:47 -0800
SubjectStruggling with unittest discovery - how to structure my project test suite
Message-ID<8607d86e-8fcf-41ac-8da2-a8c137afe087@googlegroups.com>
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

[toc] | [next] | [standalone]


#62444

FromSerhiy Storchaka <storchaka@gmail.com>
Date2013-12-20 19:41 +0200
Message-ID<mailman.4440.1387561319.18130.python-list@python.org>
In reply to#62435
20.12.13 16:47, Paul Moore написав(ла):
> 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.

python -m unittest discover -s tests/functional
python -m unittest discover tests/functional

> 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!)

python -m unittest discover -s tests/functional -p test_spam.py
python -m unittest discover tests/functional -p test_spam.py
python -m unittest discover tests/functional test_spam.py

[toc] | [prev] | [next] | [standalone]


#62458

FromPaul Moore <p.f.moore@gmail.com>
Date2013-12-20 13:02 -0800
Message-ID<57bd0551-b438-4bd8-bae0-c10f494393a3@googlegroups.com>
In reply to#62444
On Friday, 20 December 2013 17:41:40 UTC, Serhiy Storchaka  wrote:
> 20.12.13 16:47, Paul Moore написав(ла):
>
> > 1. I can run all the tests easily on demand.
> > 2. I can run just the functional or unit tests when needed.
> 
> python -m unittest discover -s tests/functional
> python -m unittest discover tests/functional

Hmm, I could have sworn I'd tried that. But you're absolutely right.

Thanks, and sorry for the waste of bandwidth...
Paul

[toc] | [prev] | [next] | [standalone]


#62455

FromTerry Reedy <tjreedy@udel.edu>
Date2013-12-20 16:48 -0500
Message-ID<mailman.4444.1387576123.18130.python-list@python.org>
In reply to#62435
On 12/20/2013 12:41 PM, Serhiy Storchaka wrote:
> 20.12.13 16:47, Paul Moore написав(ла):
>> What's the best way of structuring my projects so that:

It depends on your tradeoff between extra setup in the files and how 
much you type each time you run tests.

>> 1. I can run all the tests easily on demand.

I believe that if you copy Lib/idlelib/idle_test/__init__.py to 
tests/__main__.py and add
   import unittest; unittest.main()
then
   python -m tests
would run all your tests. Lib/idlelib/idle_test/README.py may help explain.

>> 2. I can run just the functional or unit tests when needed.
>
> python -m unittest discover -s tests/functional
> python -m unittest discover tests/functional

Ditto for __main__.py files in each, so
   python -m tests.unit (functional)
will work.

>> 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!)
>
> python -m unittest discover -s tests/functional -p test_spam.py
> python -m unittest discover tests/functional -p test_spam.py
> python -m unittest discover tests/functional test_spam.py

'discover' is not needed for single files.  For instance,
   python -m unittest idlelib.idle_test.test_calltips
works for me. One can extend that to test cases and methods.
python -m unittest idlelib.idle_test.test_calltips.Get_entityTest
and
python -m unittest 
idlelib.idle_test.test_calltips.Get_entityTest.test_bad_entity

If you add to each test_xyz.py file
   if __name__ == '__main__':
     unittest.main(verbosity=2)  # example of adding fixed option
then
   python -m tests.unit.test_xyz
will run the tests in that file. (So does F5 in an Idle editor, which is 
how I run individual test files while editing. I copy the  boilerplate 
from README.txt or an existing test_xyz.py file.)

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web