[rfc] testtools test fixtures

[Martin Pool]

Thanks for reading it, after talking it over I'll try and turn this
into a doctest-style description of how to use it.

> A few thoughts... in no particular order.
>
> Many domain objects do need cleaning up - OS locks being among the
> most common things (for working trees, which nearly all our tests
> use).

Right.

> I think its undesirable for fixtures to know about the test case: test
> cases provide nothing they would need (in an ideal world).

Ideally yes; it's just that they need their lifetime to be managed
(perhaps indirectly) by the test case, and they need to get some
resources (such as a choice of format and transport class) from the
test case.

After some discussion we propose to handle this by having chains of
fixtures that are added as cleanups by the test case and that then
propagate that down, and in the second case by passing an object that
provides scenario parameters down the chain.

>
> Some of your open questions seem to me to be 'do what works, there
> isn't a golden answer' - e.g. tests that damage a branch would want a
> fixture that fixes/deletes unconditionally. Or something. And I think
> some fixtures will be factories, others will be useful things
> themselves, and still others will just help arrange things
> conveniently.

Well, probably, I just wanted to think it through a bit ahead of time
so my patches weren't declined ;-) and so we could have some
consistency.
>
> "
> So if that's not acceptable we do need a way for fixtures that are created
> arbitarily far inside a dependency chain to know which TestCase (or other
> ObjectWithCleanups) should be destroying them."
> ^ That didn't make sense to me.

There needs to a chain of pointers so that eventually running tearDown
on the test case will cause tearDown to be called on all the
depended-upon objects, in the right order.  They don't actually need
to know about the TestCase but they do need to implicitly be
controlled by its lifetime.

>
> I think a trivial decorator could decorate interesting domain objects
> that don't need teardown, that are cheap to make, with a
> setUp/tearDown pair: its easier to add that, than to make things that
> need explicit removal safe with implicit gc.
>
> I think moving all non-infrastructure state from the tests will make
> things nicer overall, even though it is a tad more typing : its simply
> on the wrong object.

-- 
Martin