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
