[TIP] new discovery.py - q&a???
fuzzyman at voidspace.org.uk
Mon May 4 10:04:04 PDT 2009
Doug Philips wrote:
> Announced on twitter, but seems fair game here. :)
> voidspace All new implementation of test discovery for unittest. This time in a loader. Good start I think. :-) http://twurl.nl/nz8f4y
I'm very keen to avoid a bike-shed discussion which was why I haven't
posted it here. :-)
> Overall I would say it looks pretty nice.
> A few questions/confusions...
> Comments indicate some concern about the calling signature discrepancies with 'load_tests' in a module vs. in a package. Function overloading is a pain in Python. But I was confused not by the calling signature, but by the use. In a module context, 'load_tests' is really a filtery kind of thing where as in a module context it is only a filter by a stretch of filtering nothingness into a sequence of tests. :)
I assume you mean:
In a *package* context, 'load_tests' is really a filtery kind of
thing where as in a module context it is only a filter by a stretch of
filtering nothingness into a sequence of tests. :)
In *both* contexts it allows the package / module to completely
customize how tests are loaded. It is used in packages for discovery, so
the filter pattern is passed in so that the package *can* (but is not
required to) continue discovery but customize how it is done.
> I was also a little bit surprised to find that will all the optional parameters flying around everywhere, that TextTestRunner would hard coded. Not sure that it bothers me given the context, but found it odd.
TextTestRunner is only hard coded in the discover function (and could
easily be made a parameter - but the function body is only 3 lines long
so creating your own version is absurdly easy).
loader.discover(...) returns a test suite as normal and can be used in
any which way you please...
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
More information about the testing-in-python