| Thread Previous • Date Previous • Date Next • Thread Next |
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 bzrlib.transport. Really, there ought to be a zope Interface that they both implement, then it would be clearer that the tests are for that interface. lp.code.xmlrpc.tests.test_codehosting.(CodehostingTest|AcquireBranchToPullTestsViaEndpoint) 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. cheers, jml [1] https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements
| Thread Previous • Date Previous • Date Next • Thread Next |
