[rfc] add a TestFactory class or concept

[Martin Pool]

2009/8/14 Aaron Bentley <aaron at aaronbentley.com>:

>> .. so I'd like to work out what's wrong with what Launchpad does too,
>> so as not to repeat it, if there's anything else you can think of.
>
> Separating the test factory class from the test case means more typing
> for two reasons:
>
> 1. The name of the factory object must be specified.
>
> When writing tests for Launchpad, I usually subclass the
> TestCaseWithFactory, which has a member named "factory".  So instead of
> typing "self.makePerson", I must type "self.factory.makePerson".

That could get a bit annoying.  I think the TestCase has quite a lot
of responsibilities at the moment, but we do already inject scenario
dependencies into it, so it'd be reasonable to put these methods
there.

>> Generally speaking we add make_* methods on various test classes,
>> rather than centralizing them.  Many of them are things that could be
>> more broadly reused.
>
> This wasn't a problem I had noticed.  We have make_branch and
> make_branch_and_tree, and I thought you were proposing making them
> harder to use.  If instead, you're saying "make_branch is one honking
> great idea, let's do more of them", then I'm 100% in favour.

Actually, after this discussion, maybe that is the main thing I'm
saying: look for repeated code that ought to be in a make_*, and then
think about lifting it to a super class.

In general I think the tests ought to only specify properties they
actually care about or are going to examine.

> In general, I don't see the advantages in speed being worth the cost in
> simplicity.
>
> MemoryTree is not close enough to a real working tree for me to be
> comfortable with it.  I don't trust it to do what I want, and I don't
> trust it to be a good enough emulation of a working tree.  I'd rather
> use a PreviewTree, since I know and trust the TreeTransform interface.

Right, given someone else was just confused about this perhaps we
should unify them or remove one.

> BranchBuilder-- well, no compelling case has been given to me for using
> it.  It wouldn't be appropriate for me to comment further until I
> understand what it's meant for.

They are useful in the kind of case John discussed, but I have to
agree that the interfaces are a bit less obvious to use than the
regular one.  But I see that as more of a bug in BranchBuilder than a
problem with the concept of having an abstracted way for tests to say
what kind of history they want.

It feels a bit like the early days of test scenarios: test scenarios
themselves are a great idea, but the first implementation was rather
black magic and therefore wasn't used consistently across the code
base, which made it even harder to understand.

-- 
Martin <http://launchpad.net/~mbp/>