launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Jul 26, 2010 at 11:31 AM, Jeroen Vermeulen <jtv@xxxxxxxxxxxxx> wrote:
> On 2010-07-26 11:45, Jonathan Lange wrote:
>
>> I'm very glad you've got unit tests for this code, but I think it
>> would be better still if we tested the fake librarian and the real
>> librarian with the same set of tests. That way we can be confident
>> that our fake isn't masking bugs.[1]
>
> That's definitely one of the things I wanted to try if/when taking this
> further.  *Full* test compatibility would be a bridge too far though:
> support for adding files remotely doesn't make much sense for what the fake
> librarian is meant to achieve.  And then there's notions like failover and
> networking errors that just don't exist in the fake librarian.

Undoubtedly.

The principle is testing the interface. bzrlib has a good example of
this. There is one set of tests which is run against every single
Transport implementation, including the fake in-memory transport.
However, each transport also has its own set of unit tests for
specific implementation details.


>> What does moving the Librarian out of the LaunhpadLayer into a new layer
>> win?
>
> On the one hand it'd be an effective way of moving over all tests that don't
> need the full librarian.  On the other hand, some of us have been feeling
> that the name LaunchpadLayer is too "attractive" in the first place given
> that it fires up such a heavyweight service.

My bad. I had confused the LaunchpadLayer with the LaunchpadFunctionalLayer.

If I were going to do deep surgery on layers like this, I'd look for
ways to avoid using layers to indicate that tests need the Librarian
(almost certainly using testresources).

> On the gripping hand, we don't want to promulgate layers unnecessarily.  We
> might as well enable the fake in the lowest layer that will support it.  But
> we'll want a way to recognize and fix Librarian-using tests that the fake is
> good enough for.

It's a good principle to provide as little implicit test set up as
possible. Much better for tests to explicitly say they need a
librarian.

jml