On Sat, 2010-02-13 at 01:04 +0000, Michael Foord wrote:
> > However from this example I *cannot* guess whether those resources are
> > set up and torn down per test or per test class.
> This particular example is the equivalent of setUpClass - so by
> declaring the resource as a class attribute it will created before the
> first test for the class is run and disposed of after the last test for
> the class.
>
> You could *also* create a single resource and share it between several
> test classes, or even across classes in several modules, and have it
> created and disposed of at the right point. I've copied Rob Collins in
> on this email in case I've misunderstood.
Yes, precisely.
> > Also the notation
> >
> > resources = [('workdir', MyTempDir())]
> >
> > looks pretty ugly -- if 'workdir' ends up being an instance attribute,
> > why not make it a dict instead of a list of tuples? Or even better, a
> > could each resource become a class variable?
I have two key 'todos' planned in the notation for testresources:
- I want to make a decorator to let individual tests (rather
than /just/ class scope as currently happens) get resources easily.
Something like
@resource(workdir=MyTempDir())
def test_foo(self):
pass
Secondly, I want to make the class level 'resources' list into a dict.
It was a list initially, for misguided reasons that no longer apply, and
it would be much nicer and clearer as a dict.
> >
> I guess we could introspect the class for every attribute that is a
> resource, but I prefer some way of explicitly declaring which resources
> a TestCase is using.
I could see doing the below as an alternative:
@resource(workdir=MyTempDir())
class TestFoo(TestCase):
...
I'm not personally very keen on inspecting everything in self.__dict__,
I suspect it would tickle bugs in other unittest extensions. However I'm
not really /against/ it - I don't think it will result in bad test
behaviour or isolation issues. So if users would like it, lets do it.
-Rob
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
