On 10/22/2014 9:29 AM, Benjamin Smedberg wrote: > Is there a mechanism for running single gtests that start XPCOM? Not that I know of currently. The gtest runner explicitly starts XPCOM before running tests[1]. > > With the current gtest mechanism, "normal" gtests can't start XPCOM > (NS_InitXPCOM, event loops, component manager, etc) for various reasons: > > * gtests are run in parallel and XPCOM has globals and thread-locals > which don't allow that kind of multithreading This is actually not true, gtest doesn't support running tests in parallel at all[2].
> * XPCOM doesn't support being re-initialized after it has been shut > down, and supporting that is a huge task that is unlikely to be a good > idea > > However, I've heard that there are some media tests which do > initialize XPCOM: https://wiki.mozilla.org/Media/WebRTC/Testing These are actually just CPP_UNIT_TESTS with a whole bunch of framework layered around them. They wind up linking a different version of the core code which tries to avoid linking the world[3]. > > I am currently attempting to convert at a few C++ unit tests which > start XPCOM and also end up using bits of JSAPI: > > toolkit/components/places/tests/cpp/test_IHistory.cpp uses JSAPI via > nsINode->nsWrapperCache->RootingAPI > media/webrtc/signalingtest uses nsPIDOMWindow -> nsINode -> > nsWrapperCache -> RootingAPI > > I'd like to convert these to be use the gtest-libxul. Do we have a > framework for gtests that start XPCOM and therefore need to be run one > at a time rather than using the normal parallel-gtest mechanism? > I think we could feasibly make this work by defining a new test type that would spawn a new instance of the test runner with parameters to execute just the current test (obviously checking if it's already been re-invoked) in a way that doesn't init XPCOM. I don't think there's anything in the gtest framework that supports this use-case directly. The closest thing it has is "death tests" which execute a test in a new process to be able to assert that it crashes, but I don't think the underlying mechanism is exposed in a useful way. It looks like people have wanted similar things in the past, I found this post[4] with a little searching. Alternately (and possibly more simply) we could handle this in the Python test runner by enforcing a naming convention for this type of test (TestFooNoXPCOM?), making the test runner list all the tests and then run separate processes for the normal tests, and one each for the NoXPCOM tests. -Ted 1. http://dxr.mozilla.org/mozilla-central/source/testing/gtest/mozilla/GTestRunner.cpp#86 2. https://code.google.com/p/googletest/wiki/FAQ#Does_Google_Test_support_running_tests_in_parallel? 3. http://dxr.mozilla.org/mozilla-central/source/media/mtransport/standalone/moz.build 4. http://osdir.com/ml/googletestframework/2010-09/msg00025.html _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
