launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #08247
Re: help with yuixhr_fixture tests in my useoops branch
On Sun, Oct 30, 2011 at 1:55 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
> I didn't look at the which specific tests were triggering the problem, but in general, yeah, this suite tests the testing machinery itself, so it wants to trigger problems and see how they are reported and so on.
>
> You might be right about the race condition. Some of your diagnosis doesn't quite click with me yet, but I like the plan you sent on the follow-up email: file a bug, add a workaround, I'll try to get my branches landed in spare moments, and I'll follow up with you in two weeks. Thank you for offering such a considerate option. :-)
tl;dr: not yuixhr's fault at all, its just the victim.
Bug 883980. I've pinned it down exactly. This is what happens:
Test runner sets up rabbit etc because of the layer the test is in.
This updates the testrunner-appserver-XXXX config.
Test runner starts slave appserver.
Slave appserver parses ZCML and gets the *test runner* utility
configuration (e.g. the dynamically allocated DB etc).
Slave appserver calls BaseLayer.setUp() which restarts the test
environment isolation: it reverts back to testrunner-appserver (and
then allocates a transient layer on top of it).
This means we can't pass OOPSes *or any other transiently allocated
resource* from the slave appserver to the testrunner.
I've marked the bug high, and I think the fix is just to nuke /all/
the layer setup calls in the runtestappserver codepath: trust the
parent testrunner to allocate DB, librarian, rabbit etc, and make the
test appserver as lightweight as possible. This will make bringing it
up and down faster, permit assertions in the main testprocess code
(like 'no oopses were created during this test', or 'the librarian had
4 requests made to it').
For now, I'm landing a workaround: remove the 'INTERACTIVE_TESTS' flag
that was used to prevent rabbit starting - my code makes rabbit
desirable always, and we're going forward on that, not backwards.
-Rob
Follow ups
References