Re: c++ unit test in content process
On 10/03/2014 08:59 AM, Benjamin Smedberg wrote: On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. I agree. This was hard for me to accept when I first started working on the JS engine. It seemed like there should be more C++ unit tests. And maybe if there were, we'd have a better, less spaghetti-coupled design at that level. But as it stands, both in the JS engine and in Gecko generally, the dependencies are such that bootstrapping one subsystem usually amounts to firing up the whole thing. Mocking the rest of the browser is a long hard road. The good news is, using integration test frameworks to test unit functionality works astonishingly, deplorably well in Gecko. A mochitest often lets you target the exact code you wish to test using a tiny amount of HTML and JS. And it isolates your test from all sorts of future C++-level API churn. That said, if you see ways to improve the situation, go strong. The reason we have tests and a testing culture here at all is herculean efforts from Rob Sayre and others who saw what needed doing and did it. -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
And as “bad” as it is, it’s as good as it gets, and it will only get worse - unless we continue the efforts to make things better. Sometimes it’s a long haul, and you can’t get the approval to spend a lot of time digging out of some places, but often even small things help. -- - Milan On Oct 6, 2014, at 11:21 , Jason Orendorff jorendo...@mozilla.com wrote: On 10/03/2014 08:59 AM, Benjamin Smedberg wrote: On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. I agree. This was hard for me to accept when I first started working on the JS engine. It seemed like there should be more C++ unit tests. And maybe if there were, we'd have a better, less spaghetti-coupled design at that level. But as it stands, both in the JS engine and in Gecko generally, the dependencies are such that bootstrapping one subsystem usually amounts to firing up the whole thing. Mocking the rest of the browser is a long hard road. The good news is, using integration test frameworks to test unit functionality works astonishingly, deplorably well in Gecko. A mochitest often lets you target the exact code you wish to test using a tiny amount of HTML and JS. And it isolates your test from all sorts of future C++-level API churn. That said, if you see ways to improve the situation, go strong. The reason we have tests and a testing culture here at all is herculean efforts from Rob Sayre and others who saw what needed doing and did it. -j ___ 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: c++ unit test in content process
On Mon, Oct 6, 2014 at 8:21 AM, Jason Orendorff jorendo...@mozilla.com wrote: That said, if you see ways to improve the situation, go strong. The reason we have tests and a testing culture here at all is herculean efforts from Rob Sayre and others who saw what needed doing and did it. srsly. That guy rocked. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
I see. I'll try to write with a more end-to-end test framework then. Thank you. Patrick On 10/3/14 9:59 PM, Benjamin Smedberg wrote: On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform smime.p7s Description: S/MIME Cryptographic Signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
c++ unit test in content process
Hi, I am trying to write a C++ unit test for code that runs in child process, but all c++ tests I found run in parent process. Is it possible to write a c++ test case that runs in child process, or is there any example in our code? Thanks, Patrick smime.p7s Description: S/MIME Cryptographic Signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
On 10/3/2014 4:59 AM, Patrick Wang wrote: Hi, I am trying to write a C++ unit test for code that runs in child process, but all c++ tests I found run in parent process. Is it possible to write a c++ test case that runs in child process, or is there any example in our code? Could you be more specific? We have the following possible harnesses: gtest - typically these tests are low-level C++ tests and often don't initialize XPCOM at all. Certainly they don't have the concept of chrome/content processes. xpcshell - typically test the API surface of a component written in JS or C++ Neither of these particularly care about chrome/content: if you're actually testing a C++ component and not doing integration testing, is it possible that you don't need to care? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
On Fri, Oct 3, 2014 at 5:44 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 10/3/2014 4:59 AM, Patrick Wang wrote: Hi, I am trying to write a C++ unit test for code that runs in child process, but all c++ tests I found run in parent process. Is it possible to write a c++ test case that runs in child process, or is there any example in our code? Could you be more specific? We have the following possible harnesses: gtest - typically these tests are low-level C++ tests and often don't initialize XPCOM at all. Certainly they don't have the concept of chrome/content processes. xpcshell - typically test the API surface of a component written in JS or C++ Neither of these particularly care about chrome/content: if you're actually testing a C++ component and not doing integration testing, is it possible that you don't need to care? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform More importantly, our C++ tests don't start up Gecko. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Patrick On 10/3/14 8:44 PM, Benjamin Smedberg wrote: On 10/3/2014 4:59 AM, Patrick Wang wrote: Hi, I am trying to write a C++ unit test for code that runs in child process, but all c++ tests I found run in parent process. Is it possible to write a c++ test case that runs in child process, or is there any example in our code? Could you be more specific? We have the following possible harnesses: gtest - typically these tests are low-level C++ tests and often don't initialize XPCOM at all. Certainly they don't have the concept of chrome/content processes. xpcshell - typically test the API surface of a component written in JS or C++ Neither of these particularly care about chrome/content: if you're actually testing a C++ component and not doing integration testing, is it possible that you don't need to care? --BDS smime.p7s Description: S/MIME Cryptographic Signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
On 10/3/2014 9:46 AM, Patrick Wang wrote: The test I am writing is to test an implementation of WebRTC's TCP socket in content process. These codes are build on top of TCPSocket's IPDL in C++ and don't have IDL so it cannot be called directly from JS, and the tests for chrome process version are written with gtest. Therefore I am thinking of writing a similar one with gtest but run in content process. Does the unit of code you're testing include two processes communicating via IPDL? If so, I think you're going to need something more than a C++ unit test, and should probably focus your efforts on a more end-to-end integration test. Setting up IPDL connections and all of the machinery that goes with that doesn't sounds like something we should be trying in low-level unit tests. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: c++ unit test in content process
Sadly, the WebRTC gtest-based ones (e.g., media/webrtc/signaling/test) do. On Fri, Oct 3, 2014 at 6:04 AM, Kyle Huey m...@kylehuey.com wrote: On Fri, Oct 3, 2014 at 5:44 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 10/3/2014 4:59 AM, Patrick Wang wrote: Hi, I am trying to write a C++ unit test for code that runs in child process, but all c++ tests I found run in parent process. Is it possible to write a c++ test case that runs in child process, or is there any example in our code? Could you be more specific? We have the following possible harnesses: gtest - typically these tests are low-level C++ tests and often don't initialize XPCOM at all. Certainly they don't have the concept of chrome/content processes. xpcshell - typically test the API surface of a component written in JS or C++ Neither of these particularly care about chrome/content: if you're actually testing a C++ component and not doing integration testing, is it possible that you don't need to care? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform More importantly, our C++ tests don't start up Gecko. - Kyle ___ 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
