← Back to team overview

launchpad-dev team mailing list archive

Re: InMemoryFrontend


On 5 November 2012 17:06, j.c.sackett <jcsackett@xxxxxxxxxxxxx> wrote:
> Hey Jonathan--
> I recently have been working on some bugs in codehosting on launchpad, which
> brought me into contact with the InMemoryFrontend. In trying to grok this
> thing, I was directed to email you.
> Given your work on this dates from quite some time ago, I understand if you
> don't remember any of it, but here's hoping.
> What exactly is the InMemoryFrontend's purpose? It seems to exactly ape the
> DatabaseFrontend in functionality, except that in various places rather than
> calling code that should error, it just checks for the error condition's
> presence and then returns the fault.
> It seems to be a test mock, except in many places it and the DatabaseFrontend
> are run against the same tests.

Right, it's a test double. It's particularly used so that the vfs
tests run quickly.

The reason it and DatabaseFrontend are run against the same tests is
so that the behaviour of the two don't skew. We copied the idea from

Really, there ought to be a zope Interface that they both implement,
then it would be clearer that the tests are for that interface.
are the interface tests.

lp.codehosting operates along similar principles to the SOA /
micro-service stuff that Robert Collins outlined during his stint as
technical architect[1]. The actual codehosting server doesn't talk
directly to the Launchpad database, but communicates with it via
XML-RPC. So, to test the virtual file-system that it implements,
rather than spinning up a Launchpad appserver, it provides a fake one.

test_branchfs, test_branchfsclient, test_filesystem and test_transport
are the tests that use it.

> My hope is it had reasons for existing, but doesn't anymore and can be
> deleted. Do you have any memory of its reason for existing or why trying to
> kill it would be a really bad idea?

Doing that would make the test suite run more slowly and couple
codehosting more tightly to the rest of the Launchpad. So, I guess
kill it only if you think the benefit makes up for that.

I'll admit that as test doubles go, it's pretty cumbersome. At the
time, I couldn't think of a better way. I can't recall yet if I've
apologized in this email, but that seems the thing to do when talking
about code now left for others to maintain. Sorry.

If you are doing work in the area, I would suggest making it a proper
microservice and moving it off to another code base.

Hope this helps.


[1] https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements