On 5/8/2013 8:41 AM, Ethan Hugg wrote:
Hi All,
We currently have 10 C++ GTest unittests in Firefox in
media/mtransport/test and media/webrtc/signaling/test that build standalone
tests with the FF build. These tests currently run as part of the build
and make the B orange if they fail which is why a couple of them are still
stubbed at runtime based on an environment variable.
I am looking into getting them to build on Windows (Bug 862837). This
appears non-trivial because of the different way the Windows build links.
It was suggested by Ted that we move them to the new firefox GTest which
would build them only with --enable-gtest and run as part of 'firefox
-unittest'.
So, for those of you interested, my questions are:
1. If they were moved into the standard Gtest, would they still be built by
tbpl and run with the tests instead of as part of the build?
Currently, we have no gtest coverage on checkins. That will change with
bug 844288.
Initially, we will roll gtest into |make check|, which means they will
be executed as part of checkin. There is a movement to split out
long-running components of |make check| into their own automation jobs
so tests don't always run as part of the build step. See
https://bugzilla.mozilla.org/show_bug.cgi?id=822394#c3 for part of that.
But, I don't think the eventual split of |make check| is of concern to
many at this juncture.
2. One of them in particular (signaling_unittest) is fairly large and takes
minutes to run. Should it be run separately by using GTEST_FILTER?
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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
