That's a fair point, but if someone else causes his test not to run
(intentionally or not), he (not I) is going to fix it, most likely. If
I'm making test changes, I certainly check that they all run correctly
and I get 0 failures. Beyond that, I tend not to worry TOO much about
others' tests, as I try not to make changes (even test fixes) in areas
outside my own without talking to the owner, which gets us back to him
(or her ;) fixing the broken test. :)
My suggestion below is not a hard and fast rule, of course, but is
generally what I live by when I'm checking the results of my daily
cron'd full build.
On 8/10/11 10:00 AM, Ed Burns wrote:
>>>>>> On Tue, 09 Aug 2011 17:25:25 -0500, Jason Lee<jason.d.lee_at_oracle.com> said:
> JL> Personally, if it says 0 failed, I'm happy, regardless of how many
> JL> passed. :)
>
> Certainly, but asserting for 0 failed does not detect the case where a
> test should have executed and passed but did not even get called. This
> can happen if the build environment has some kind of misconfiguration,
> or even due to some configuration problem on the hudson job.
>
> In my experience, the difficulty of consistently ensuring that all the
> tests that are supposed to run are actually run increases dramatically
> the more large and dispersed a team is.
>
> Does anyone else here share this opinion?
>
> Ed
>
--
Jason Lee
Senior Member of Technical Staff
GlassFish REST API / Administration Console
Oracle Corporation
Phone +1 405-216-3193
Blog http://blogs.steeplesoft.com