Christoph Zwerschke wrote: > I wasn't aware of the py lib so far. The > possibility to create fixtures at the three different scopes is exactly > what I was looking for. > > Anyway, I think it would be nice to have that feature in the standard > lib unittest as well. It should not be too hard to add setUpOnce and > tearDownOnce methods in addition to setUp and tearDown. Actually, I am > wondering that there doesn't seem to be any development progress since > unittest was included in the standard lib of Python 2.1 in August 2001. > I had expected that such an important module would be continually > improved and maintained. How come? So few people using unit tests? Or do > most people write their own testing code or use py.test?
Voice of Mr. Unittest: """ The details of the implementation are not nearly as important as the test cases. If you can support a set of test cases like the ones given here, then you can write tests that are isolated and can be composed, and you will be on your way to being able to develop test-first. . . . The spirit of xUnit is simplicity. . . . Some of the implementations have gotten a little complicated for my taste. """ -- Kent Beck, Test Driven Development, p. 119. Python's unittest module is already a bit to complicated. Building it out further would be a step in the wrong direction. As it stands now, it is somewhat powerful and flexible without being overly difficult to learn. FWIW, it does not take much skill to use the existing unittest module to meet advanced testing needs. Lib/test/test_decimal.py has few lines that dynamically build a whole suite of tests from a directory of text resource files. Lib/test/test_compiler.py has just a few lines to shorten testing time by running a random subset of tests. Lib/test/test_deque.py has a handful of lines to run the suite multiple times to check reference counts and it incorporates a doctest suite to verify the examples in the documentation. Your own feature request for setUpOnce() and tearDownOnce() is trivially coded using a global or class variable to restrict running to a single occasion. If that seems unpleasant, then encapsulate the logic in a subclass of TestCase, in a decorator, or in a metaclass. If you want better, try py lib's py.test module which is both more minimalistic and more powerful. Raymond P.S. The above is based on the experience of writing thousands of lines of test code. The existing unittest module is just fine without further buildout. If it weren't for backwards compatibility issues, I would recommend pairing it down further -- only a small subset of its features are necessary to meet most needs. -- http://mail.python.org/mailman/listinfo/python-list
