918110 - Better integration for e10s xpcshell tests

Status: NEW

(Testing :: XPCShell Harness, defect)

Description

[Jason Duell]

Right now to get e10s coverage for an xpcshell test you need to create a separate file ("test_foo_wrap.js") and store it in a separate 'unit_ipc' directory.  95% of the time that file is a one-liner that could be generated automatically:

  run_test_in_child("../unit/test_foo.js");

I kludged this scheme together years ago, and it sucks for various reasons:

1) we don't get e10s coverage by default: it's opt-in, and many people forget to add e10s versions of tests.

2) It's pointless effort that can usually be automated

The one nice thing about it is that for the 5% case where you need to do something (usually modify prefs) in the parent before/during the child-side test, you can do that.

I'd really like to see us use a scheme that integrates e10s testing into xpcshell.ini, so that it 1) gets turned on by default, with some sort of 'skip-if = mode == e10s' to disable e10s; 2) the logic to run in child is handled by runxpcshell instead of hand-rolled; and 3) we provide a way to hand-roll things for the 5% case.

It's unlikely I'm going to find time for this, so consider it a feature request.  It would be especially helpful to have this early in the desktop e10s development cycle. (cough-yesterday-cough :)

Comment 1

[(not currently active) Ted Mielczarek]

This sounds pretty reasonable. How about this as a proposal?
* All tests get dual-run: once as a normal xpcshell test, and once in e10s mode (effectively using your one-liner)
* We add a manifest annotation to opt tests out of running in e10s mode, like "e10s = false" or "ipc = false".
* We add an additional annotation to specify an extra JS file that will be executed in the parent process before executing the child process. (Presumably with messaging that would let you do anything you needed to cross-process.) Something like "ipc-parent-script = parent.js".

I don't think the sum of this is a huge amount of work, just needs someone to do it. CCing mihneadb who recently reworked most of the xpcshell harness, not sure if he has any cycles for something like this now that he's back at school (but it can't hurt).

Comment 2

[Mihnea Dobrescu-Balaur (:mihneadb)]

Sounds like a good idea. How would we do this at runtime? Create a dummy temp file which does run_in_child(TEST_FILE) and pass that to xpcshell?

I'll be away for the next week and I'm not sure how much I can get done by then but after that I should be able to help.