On Mon, Jul 26, 2010 at 11:31 AM, Jeroen Vermeulen <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
