Re: When to commit failing tests (was: Re: svn commit: r17032 - trunk/subversion/tests/clients/cmdline)
On 26 Oct 2005 12:43:57 -0500, email@example.com <firstname.lastname@example.org> wrote:
> "Peter N. Lundblad" <email@example.com> writes:
> > You normally don't commit something that you know have failing tests. If
> > the nightly build fail, because you did something platform-dependent or
> > something, then that's another story. I really don't think knowingly
> > commit failing tests non-XFail is a good way of alerting people that there
> > is a regression. You can post to dev@, file an issue or just fix it in a
> > few days.
> > The problem with your approach is that it slows down things for everyone
> > else. When I want to run tests and get a failure, I have to examine and
> > dscover that it was just that other regression that still fails. If I made
> > a commit, I have to examine the nightly failure mails, because I can't
> > just assume that it is your test that fail. I think that's a waste of
> > time.
> +1 IMHO.
> The value of the test suite and the nightly builds is in notifying us
> of things we don't already know. So if someone knows that a test is
> failing, then we don't need to get that information by other means --
> the person can just set the test XFail, and file an issue or do
> whatever is appropriate, to record the fact of the failure.
I am +1 on Peter's point of view. Also we can add rule that any XFail
test should have issue. And keep issue number written near XFail test?
It prevent forget bugs.
Received on Wed Oct 26 22:14:21 2005
This is an archived mail posted to the Subversion Dev