Open Bug 1799977 Opened 1 year ago Updated 11 months ago

Support non-browser-chrome-flavoured mochitests for FOG instrumentation

Categories

(Toolkit :: Telemetry, enhancement, P2)

enhancement

Tracking

()

People

(Reporter: chutten, Unassigned)

References

(Blocks 1 open bug)

Details

FOG supports a variety of ways to test instrumentation. One of the ways it doesn't is non-browser-chrome-flavoured mochitests.

This is in no small part due to the test code tending to run in a content child process, where test APIs (like testGetValue) will specifically panic.

For bug 1401592 :bwc and I designed and :bwc wrote a fun Proxy-based way of providing a very Glean-like test API in even this case. (A key design point is noting that the inter-process nature makes these APIs asynchronous, so changing the name of the proxy to GleanTest helps people realize there's something different afoot)

We should adapt this design and expand it:

  • Make it available to all of these tests across the tree (perhaps via SpecialPowers?)
  • Add support for labeled metrics (Glean[category][metric][label]testGetValue())
  • Add support for the optional aPingName argument to testGetValue
  • Add support for pings (both testBeforeNextSubmit and submit)
  • User Documentation for how to use it (over here)
    • If needed: Dev Documentation for how it was built (if it needs more explaining than the code can provide)
  • FOG tests (in toolkit/component/glean/tests/) to ensure it works (and continues to work) as documented

Or, if the design won't support all this, this bug expands to include a design proposal step with the above serving as a (partial) requirements list.

Blocks: 1670259

While we're in the area, update the docs for IPC-aware instrumentation tests to have await before calls to Services.fog.testFlushAllChildren(). It returns a Promise, after all.

Question for someone who had opinions about how we exposed Glean and GleanPings globals in privileged JS scopes (so, :smaug): Is there a best practice to follow for providing test APIs to plain mochitests? Is it "hang it off of SpecialPowers"?

Flags: needinfo?(smaug)

Yes, SpecialPowers. What all needs to be available?
Is just SpecialPowers.wrap(window).Glean not enough?
https://searchfox.org/mozilla-central/rev/32c74afbb24dce4b5dd6b33be71197e615631d71/testing/specialpowers/content/SpecialPowersChild.sys.mjs#344-373

Flags: needinfo?(smaug)

TIL, and wow wrap is pretty darn amazing... but alas not. What we really need is access to the parent's Glean and GleanPings (since the parent's where the data lives). See the use of spawnChrome.

I'm guessing we'll be constructing a spawnChrome-based Proxy similar to how its done there, but doing so in a common location (I went looking for a toplevel head.js, but that doesn't really exist, does it. I see where we add utils so maybe that's the route I should pursue instead? Or maybe there's yet a different pattern to follow for something that is only needed in certain kinds of tests (instrumentation tests))

Flags: needinfo?(smaug)

Ah, if you need to run JS in the parent process, spawnChrome looks like a very reasonable approach.
Do we expect glean stuff to be tested in many different places, or could the helper code just live in some separate script which is included in the relevant tests?

Flags: needinfo?(smaug)

As many places as Telemetry is tested today. I suppose we could start with a GleanMochitestUtils module and instruct people on how to use it. If it becomes so popular that it's worth adding to the list then that's a nice problem to solve.

Thank you for your help, I believe I have a way forward now. If you have a moment more to spend here, would you happen to know a good example of "separate script which is included in the relevant tests" so I don't cargo cult some bad habits from other uses of SpecialPowers.ChromeUtils.import?

You need to log in before you can comment on or make changes to this bug.