Closed Bug 1448188 Opened 2 years ago Closed 2 years ago

Stand up GeckoView tests using e10s

Categories

(GeckoView :: General, enhancement, P1)

Unspecified
Android
enhancement

Tracking

(firefox59 wontfix, firefox60 wontfix, firefox61 fixed)

RESOLVED FIXED
mozilla61
Tracking Status
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- fixed

People

(Reporter: cpeterson, Assigned: jchen)

References

Details

(Whiteboard: [geckoview:klar])

Attachments

(1 file)

We want to be able to test GeckoView using e10s and standalone without Fennec. We might need to limit these tests to the Android x86 emulators because the real devices are so slow.
Need to build test APK in automation. Once we are building the test APK, gbrown said he could take over standing up the tests. This bug is not dependent on standing up the x86 emulators.
Assignee: nobody → nchen
Priority: -- → P1
Summary: Stand up GeckoView tests using e10s (on x86 emulator?) → Stand up GeckoView tests using e10s
Whiteboard: [geckoview:klar]
Attachment #8965002 - Flags: review?(nalexander)
Comment on attachment 8965002 [details]
Bug 1448188 - Build geckoview instrumentation test in automation;

https://reviewboard.mozilla.org/r/233738/#review239474

This looks fine -- if it's green on try, it's good for me.

I feel like I talked to snorp about this, but by pushing the androidTest compilation into |mach android archive-geckoview|, you won't see changes when running |mach build| locally.  I feel like you will get frustrated "breaking the build" when you just busted GV test compilation... but I'll let that be your decision.
Attachment #8965002 - Flags: review?(nalexander) → review+
Blocks: 1445716
That's a good point. I tried moving :geckoview:assembleAndroidTest to the assemble-app step, but looks like that depends on building GeckoView first through geckoview:assemble (because of GV's special omni.ja, etc), and I'm not sure we want to be spending more time building all of GeckoView during |mach build/package|. So I think I'll leave it like this for now?
Pushed by nchen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d533d09f17f8
Build geckoview instrumentation test in automation; r=nalexander
(In reply to Jim Chen [:jchen] [:darchons] from comment #4)
> That's a good point. I tried moving :geckoview:assembleAndroidTest to the
> assemble-app step, but looks like that depends on building GeckoView first
> through geckoview:assemble (because of GV's special omni.ja, etc), and I'm
> not sure we want to be spending more time building all of GeckoView during
> |mach build/package|. So I think I'll leave it like this for now?

That's fine by me.  I don't know what the long-term evolution of all this is, and I'm happy to have you drive that.
https://hg.mozilla.org/mozilla-central/rev/d533d09f17f8
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Geoff, now that we will be building a GeckoView androidTest APK, what are the next steps for running standard reftests and mochitests in GeckoView?
Flags: needinfo?(gbrown)
The next thing I am focused on is bug 1445716 - running these geckoview junit tests in automation, on existing emulators.

It looks to me like it is almost possible to run mochitests and reftests locally in geckoview_example, except for a hiccup on shutdown -- I've just filed bug 1452399 to sort that out.

:bc is making progress on running tests on bitbar devices which is turning up some issues around running tests on newer versions of Android; we're both investigating.

Beyond those issues, to run geckoview mochitests and reftests in automation, we intend to run against new x86 emulators on packet.net, but are currently blocked waiting for taskcluster support for packet.net.
Flags: needinfo?(gbrown)
I think we want to eventually be using TestRunnerActivity, which is different from geckoview_example/GeckoViewActivity, for mochitests/reftests (Bug 1291387). TestRunnerActivity is included in the new androidTest APK.
Product: Firefox for Android → GeckoView
Target Milestone: Firefox 61 → mozilla61
You need to log in before you can comment on or make changes to this bug.