[TIP] including tests in packages, or not
olemis at gmail.com
Mon Sep 21 07:46:22 PDT 2009
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,
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 !
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Solo 12 minutos ... para volver a nacer -
More information about the testing-in-python