[TIP] new discovery.py - q&a???

Michael Foord 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...
> understood.
> -Doug


More information about the testing-in-python mailing list