Re: gtests that start XPCOM
Like Ted mentions GTest doesn't support running test in parallel -in the same process-, you have to launch multiple processes which the ./mach gtest command helps you do. Currently GTest has a ScopedXPCOM thing. I'm not sure exactly what this implies however: http://mxr.mozilla.org/mozilla-central/source/testing/gtest/mozilla/GTestRunner.cpp#86 On Wed, Oct 22, 2014 at 2:07 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 10/22/2014 10:49 AM, Kyle Huey wrote: I've been wanting this too. I was thinking about just making the gtest harness itself start XPCOM. - Kyle I don't think that's quite right. 1) We'd have to serialize a bunch of tests 2) it would be really easy for tests to interfere with eachother. What I'd us to do is split gtests into two: keep the existing no-XPCOM pure parallelizable gtests, and have a separate suite which is more like a binary xpcshell tests: one process per test which uses no profile or a throwaway profile, and any parallelization is handled by the harness. It would use the same gtest-libxul so that we could compile in arbitrary test code which uses internal linkage. I'm not sure how hard that would be to implement, though. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gtests that start XPCOM
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
Re: gtests that start XPCOM
On Wed, Oct 22, 2014 at 09:29:05AM -0400, Benjamin Smedberg wrote: Is there a mechanism for running single gtests that start XPCOM? 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 * 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 AFAIK, webrtc tests are old-school C++ unit tests. 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? We don't. Currently, all gtests are run from a single instance of firefox. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gtests that start XPCOM
On Wed, Oct 22, 2014 at 4:05 PM, Ted Mielczarek t...@mielczarek.org wrote: 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] Yes. This is a mess and has required a bunch of special case code both to spin up XPCOM and to disable features of WebRTC which depend on pieces of XUL that we weren't able to get going because they pulled in too much of the world. It would be great if there were a way not to do this. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gtests that start XPCOM
On Wed, Oct 22, 2014 at 6:29 AM, Benjamin Smedberg benja...@smedbergs.us wrote: Is there a mechanism for running single gtests that start XPCOM? 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 * 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 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? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform I've been wanting this too. I was thinking about just making the gtest harness itself start XPCOM. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gtests that start XPCOM
On 10/22/2014 10:49 AM, Kyle Huey wrote: I've been wanting this too. I was thinking about just making the gtest harness itself start XPCOM. - Kyle I don't think that's quite right. 1) We'd have to serialize a bunch of tests 2) it would be really easy for tests to interfere with eachother. What I'd us to do is split gtests into two: keep the existing no-XPCOM pure parallelizable gtests, and have a separate suite which is more like a binary xpcshell tests: one process per test which uses no profile or a throwaway profile, and any parallelization is handled by the harness. It would use the same gtest-libxul so that we could compile in arbitrary test code which uses internal linkage. I'm not sure how hard that would be to implement, though. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
