unittest and automatically firing off tests

[Jp Calderone]

On Fri, Jun 20, 2003 at 09:57:37PM -0700, Tom Plunket wrote:
> I'm a long-time CppUnit TDDer and a relatively competent C++
> coder...  I'm trying to make tests that automatically fire off
> every time I run the test app, so I derive my test classes from
> unittest.TestCase, build a bunch of tests in each one called
> testSomething, and name the file test_<class_under_test>.py.
> Finally, I have test.py implemented as such:
> 
> : import unittest
> : import os
> : 
> : if __name__ == "__main__":
> :     names = os.listdir('.')
> :     tests = []
> :     for name in names:
> :         if name[:5] == "test_" and name[-3:] == os.extsep+"py":
> :             modname = name[:-3]
> :             tests.append(modname)
> :     tests.sort()
> : 
> :     for test in tests:
> :         try:
> :             unittest.main(test)
> :         except SystemExit:
> :             pass
> : 
> :     s = raw_input("\n<Enter> to continue.\n")
> :     pass
> 
> Things I don't like about this?  You bet.
> 
> 1) Why in the name of all that is holy does unittest.main() throw
>    regardless of tests passing?
> 
> 2) Why can't I readily pass a list of tests to unittest.main()? 
>    (I mean, besides the fact that it's not implemented; was this
>    a concious ommision?)
> 
> 3) I feel like I should automatically batch up tests and fire
>    them off to unittest.run() or something similar.  Is this as
>    straight-forward and easy, and could I batch them all into one
>    mega-suite?  Are there any reasons why I wouldn't want to do
>    that?

  Since all the points you bring up are related to selecting the tests to
run, and then getting them to run, I feel confident in suggested
twisted.trial, which presents an API very similar to that of unittest, but
which -also- presents a commandline tool, "trial", for selecting and running
tests.  Some examples of usage of trial:

    trial project/test/test_things.py
    trial project/test/
    trial project.test
    trial project.test.test_things.ThingyTestCase.testPrimaryThingy

  I realize I haven't addressed any unittest.py issues, but I hope this is
helpful anyway.

  Jp

-- 
It is practically impossible to teach good programming style to
students that have had prior exposure to BASIC: as potential
programmers they are mentally mutilated beyond hope of
regeneration.        -- Dijkstra