If you plan on adding more tests to GTest please build against patches in bug 844288 which will hopefully land soon. Note that I have one outstanding problem left on Windows where the linking only fails on TBPL jobs.
I personally have a strong preference for keeping tests, particularly unit tests, running fast. My workflow is to develop new code by testing it via unit tests so longer turn around times slow down my development workflow. Sadly we don't have a good a way with dealing with slow but efficient tests and they end up making it difficult to test locally. But this isn't a reason to reject a useful test so feel free to check it in. Perhaps we should consider introducing a concept of smoke tests for developers to run locally where we can aim to maintain a good trade off between code coverage and turn around times. But that's orthogonal to your request. I think splitting GTest into a separate test job should be a prerequisite to not slow down the build job significantly which AIUI reduces test turn around times by delaying all test jobs from starting. On Wed, May 8, 2013 at 1:43 PM, Adam Roach <a...@mozilla.com> wrote: > On 5/8/13 12:10, Gregory Szorc wrote: > >> I think this is more a question for sheriffs and people closer to >> automation. Generally, you need to be cognizant of timeouts enforced by our >> automation infrastructure and the scorn people will give you for running a >> test that isn't efficient. But if it is efficient and passes try, you're >> generally on semi-solid ground. >> > > The issue with the signaling tests is that there are necessarily a lot of > timers involved, so they'll always take a long time to run. They're pretty > close to optimally "efficient" inasmuch as there's really no faster way to > do what they're doing. I suspect you mean "runs in a very short amount of > time" rather than "efficient." > > It should be noted that not running the signaling_unittests on checkin has > bitten us several times, as we'll go for long period of times with > regressions that would have been caught if they'd been running (and then > it's a lot more work to track down where the regression was introduced). > > /a > > ______________________________**_________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
