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
