On 05/08/2013 08:06 PM, Benoit Girard wrote:
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
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,
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
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 w
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
5 matches
Mail list logo