Add basic support for 'mach gtest' on Android.
Handling of Android-only and desktop-only options is awkward; I hope to
re-visit this after bug 1519369.
Differential Revision: https://phabricator.services.mozilla.com/D28129
--HG--
extra : moz-landing-system : lando
Adds remotegtests.py, like rungtests.py, but for Android. Unlike some other test harnesses, remotegtests is not a sub-class of rungtests: There wasn't much code that could be re-used.
The code to wait for the test app and collect and display the log is derived from and similar to existing code in remoteautomation.py: I didn't want to increase reliance on remoteautomation; I don't mind a bit of code duplication.
There is a TODO item related to libxul.so. gtest runs in the browser, but with tests compiled into a gtest-specific version of libxul.so. remotegtests.py patches the installed app by pushing the libxul.so to the installation directory of the app -- root required and fragile, but works fine on the emulator. I think the "right" way to do this is to create a gtest-specific apk; I plan to file a follow-up bug and petition build folks to help sort that out.
I have been running this locally with:
mach gtest (builds gtests, then errors out)
mach python testing/gtest/remotegtests.py --libxul=/home/gbrown/objdirs/x86_64/dist/bin/gtest/libxul.so
Work-in-progress on 'mach gtest' will make this much simpler.
Differential Revision: https://phabricator.services.mozilla.com/D26835
--HG--
extra : moz-landing-system : lando
Desktop gtest creates minidumps in the current working directory. That is
problematic on Android, since the test app's cwd may not be writable, or
may not be readable by the test harness. This patch allows the test harness
to specify an alternate minidump path with environment variable
MOZ_GTEST_MINIDUMPS_PATH.
Differential Revision: https://phabricator.services.mozilla.com/D26833
--HG--
extra : moz-landing-system : lando
On Android, update mozilla gtest logging so that logging appears in the Android logcat.
Also, when MOZ_GTEST_LOG_PATH is defined in the environment, create the named file
and direct logging to that file. Android gtest will use this to collect gtest logging from
the device and copy it to the test log.
Differential Revision: https://phabricator.services.mozilla.com/D26610
--HG--
extra : moz-landing-system : lando
Before this change, testing/gtest had 19 errors. These errors have been resolved.
Bug 1506611 - Fixed flake8 errors in testing/gtest
Differential Revision: https://phabricator.services.mozilla.com/D15074
--HG--
extra : moz-landing-system : lando
GTest supports the TEST macro, which just runs a bunch of tests, and the
TEST_F macro, which enables writing custom test fixtures to perform
per-test setup and teardown. The benchmarking framework we have has a
corresponding macro for the former, but no corresponding macro for the
latter. If there's significant work to be done during setup and
teardown, we certainly don't want to be doing that work during the
actual benchmarking! So let's introduce a MOZ_GTEST_BENCH_F macro that
works similarly to the TEST_F macro.
Because the default "fast" variant uses fork() on !windows, death tests
are dangerous, as they themselves say. There are race conditions
involving locks that lead to dead locks in the death test process while
disabling the crash reporter (currently, but this could happen for
different code, even the tested code itself).
See https://bugzilla.mozilla.org/show_bug.cgi?id=1419196#c7 for details.
Using the "threadsafe" variant creates new processes for each death
test. This is notably slower, but can't dead-lock because of some random
lock being held by some random other thread at the moment fork occurred.
--HG--
extra : rebase_source : 56bf678bc9a6588751520549d57db7293134e1f8
This adds a moz.build file for the tests. The alternative would be to hack up
the gyp files. Since gyp support has already been removed from upstream, this
does not really buy us anything as far as maintainabily goes. Once gn support
is available in our build system, we can remove this moz.build file and use
the gn files instead.
The include paths for the gtest and gmock headers in the webrtc.org tests are
not compatible with where we export the headers. We could patch each unittest,
but the include location has already changed upstream making this painful
to maintain. Instead, we duplicate the relevant headers to the expected path.
MozReview-Commit-ID: 1ADUAMxTCFq
--HG--
extra : rebase_source : 2cc10faa7018ee8af8e8f3d7805265ed2dd89507
I've moved the mozilla specific gtest stuff to link directly in xul-gtest
rather than in the gtest static library to make it possible for standalone
programs to link against this library and not have to link
against other mozilla libraries. This allows us to build
media/webrtc/signaling/fuzztest against this version of gtest rather than the
webrtc version of gtest, which I plan to remove in a follow on bug.
I had to add a global disable for -Wgnu-zero-variadic-macro-arguments as we
hit that everywhere we use the INSTANTIATE_TEST_CASE_P macro.
This brings forward the fix from Bug 844630 to the visibility of environ in
gtest-death-test.cc.
I also removed code that set GTEST_API_ to a visibility that conflicts with
what we've defined elsewhere in tree.
MozReview-Commit-ID: 3cfuapC6vn0
--HG--
extra : rebase_source : 6e5d2684718b6ddaa5a64c1f26a0172c91b5a719