quasi-survey on writing mozmill tests for thunderbird
Pidgeot18 at verizon.net
Fri Mar 18 00:18:11 UTC 2011
On 03/17/2011 01:59 PM, Andrew Sutherland wrote:
> On 03/17/2011 07:12 AM, Joshua Cranmer wrote:
>>> - How hard is it to debug a test?
>> IIRC, some exception failures weren't properly caught by mozmill,
>> which required lots of dump statements and try/catch blocks to
>> actually figure out what was going on.
> I know it's probably fuzzy, but can you elaborate on this?
> Specifically, how long ago was this, and is it possible this is one of
> those "XPConnect eating exceptions" things (which we can mitigate
> slightly via preference; things can end up much more chatty, but it's
> likely worth it for the testing situation)?
I don't recall, since I last touched the mozmill tests in question 2
months ago and have subsequently attempted to liberally reuse those
neurons. I want to say it was an error being thrown from xpconnect or
> Was the fake-server code trying to spin its own nested event loop?
> While I think it would be preferable to have the fake-server running
> in its own dedicated thread (basically impossible with recent
> XPConnect changes) or own process, it seems like the mozmill test
> environment is roughly equivalent to the xpcshell environment, except
> that mozmill spins nested event loops all over the place and thus it's
> not safe for any other code to do the same unless the mozmill
> environment is prepared for it and able to transfer control to some
> other testing function (like we do for modal dialogs).
Yes, fakeserver requires spinning the nested event loop, which adds a
lot of complications to tests (in particular, I can attribute some
random fakeserver failures with us stopping that event loop too soon).
Being able to run it in its own thread would be simply marvelous, but
alas, that does not seem to be a tenable option. A separate process for
fakeserver might fix some of the issues, but it would require decent IPC
support which Mozilla does not in general have (since we need to
communicate daemon info in tests).
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
More information about the tb-planning