[TIP] new discovery.py - q&a???
fuzzyman at voidspace.org.uk
Mon May 4 10:32:37 PDT 2009
Doug Philips wrote:
> On or about Monday, May 04, 2009, at 01:04PM, Michael Foord indited:
>> 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. :)
> Ok, so I am even more confused: (line numbers taken from: http://twurl.nl/nz8f4y)
> Looking at _find_tests(), line 89 is testing for a file (module), and line 93 is yielding loadTestsFromModule.
> On line 25 (in loadTestsFromModule) is calling the super class to do the loading and then passing the loaded tests into the modules 'load_tests' function (if it exists), and that is the use of 'load_tests' as a filter that I was referring to.
Modules can either filter the tests or load them themselves. The logic
for loading the tests in the normal way first is that often load_tests
may just want to dynamically add additional tests or perhaps remove them
(it is not prima-facie a filter).
> On line 115 is where the package's load_tests' function is used as a filter from nothing-ness to a test sequence. :)
But collecting the tests for a package involves recursing into the test
package. load_tests allows the package to do that itself. Putting tests
into the __init__.py itself would be 'unusual' (in my opinion) so there
is not necessarily a *need* to load them from there first.
I did however add a caveat to this (early version). We could do ordinary
collection so that load_tests is called in the same way as for a package
(but with the extra include_filter not passed into the module) - however
we can't just call loadTestsFromModule on the package because that would
call load_tests again with the wrong signature.
>> loader.discover(...) returns a test suite as normal and can be used in
>> any which way you please...
More information about the testing-in-python