[TIP] including tests in packages, or not

[Olemis Lang]

On Mon, Sep 21, 2009 at 7:31 AM, Olemis Lang <olemis at gmail.com> wrote:
> On Mon, Sep 21, 2009 at 7:25 AM, Robert Collins
> <robertc at robertcollins.net> wrote:
>
[...]
>
>>> IMO, if someone needs something like this then it would always be
>>> possible to subclass TestLoader . Why should that be included in the
>>> top-level (i.e. very simple ;o) TestLoader class ?
>>
>> Why should someone have to subclass to get something that is both
>> trivial and extremely useful?
>
> Well here possibly you'r right :) ... so I wont follow ;o)
>

But anyway let me explain why I mentioned that in the first place.

  - There are some loaders that retrieve tests defined in functions and
    other callable objects. For instance,
`dutest.DocTestLoader.loadTestsFromName`
    should load doctests defined in *ANY* object (i.e. callable or
not), and not call
    the object in order to retrieve test cases.
  - Classes are callable objects, that includes TestCase, and AFAICS in this
    case the impl should be patched to say -well not all callable
objects are handled
    the same way - ... and IMO uniformity matters.

IMO a method has to be consistent and expose precise semantics (e.g.
like a contract), and I just had the impression that both cases would
conflict, but I'm probably confused | mistaken ...

BTW: What should be the semantics of `loadTestFromName` ? My (abstract
& incorrect) version is :

{{{
The loader figures out all the tests that can be extracted or
generated using the target object and brings'em to life.
}}}

Perhaps all that doesn't conflict with your initial idea ;o)

PS: Damn it !
I promised not to follow !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Solo 12 minutos ... para volver a nacer  -
http://feedproxy.google.com/~r/simelo-es/~3/L0etLsqDEBI/solo-12-minutos-para-volver-nacer.html