[TIP] Why do we need loadTestsFromPackage ?

Michael Foord fuzzyman at voidspace.org.uk
Tue Apr 14 10:11:35 PDT 2009


Olemis Lang wrote:
>> For discovery. If we do it in a new loader (and I don't see the difference
>> beyond your notional ideas of OO purity)
>> what would the interface to the
>> discovery mechanism look like?
>>
>>     
>
> {{{
> simpleloader = Loader1()
> s1 = simpleloader.loadTestsFromModule(pkg) # Just top-level module
>
>     # as usual
> discoloader = DiscoLoader(simpleloader)        # The concrete loader is
>
>     # an arg. It is used to actually
>
>     # load tests out of single
>
>     # modules whereas
>
>     # DiscoLoader handles
>
>     # listing files | modules
>
>     # and so on
>
> s2 = discoloader.loadTestsFromModule(pkg)   # All tests in pkg
> }}}
>
>   
Shoehorning discovery into loadTestsFromModule is worse - it is less 
amenable to customization as you can't customize loading tests from a 
module whilst still reusing the discovery mechanism.

Whether it is provided on the standard loader or on a subclass is not a 
very interesting question.

>> You say you don't understand why, I don't understand why not.
>>
>>     
>
> I understand that loadTestsFromPackage is a candidate. I'm not sure
> about its benefits, especially because AFAICS and IMHO there is no
> need to include loadTestsFromPackage in order to allow discovery. I
> think that the option I mentioned above is more dynamic and is
> suitable for diverse discovery strategies, varying apart of the code
> for the real | concrete loader.
>
> Could we pls keep focused on the pros & cons of both approaches with
> concrete arguments ?
>
>   
"is more dynamic and is suitable for diverse discovery strategies, 
varying apart of the code for the real | concrete loader." is not a 
concrete argument and as far as I can tell doesn't actually say anything.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog





More information about the testing-in-python mailing list