Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #62435 > unrolled thread
| Started by | Paul Moore <p.f.moore@gmail.com> |
|---|---|
| First post | 2013-12-20 06:47 -0800 |
| Last post | 2013-12-20 16:48 -0500 |
| Articles | 4 — 3 participants |
Back to article view | Back to comp.lang.python
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
| From | Paul Moore <p.f.moore@gmail.com> |
|---|---|
| Date | 2013-12-20 06:47 -0800 |
| Subject | Struggling 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]
| From | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| Date | 2013-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]
| From | Paul Moore <p.f.moore@gmail.com> |
|---|---|
| Date | 2013-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]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-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