Joachim Draeger wrote:
My personal preference is to avoid as hell committing code that will
make tests to fail. As like as committing code that does not compile or
run: of course the last one is the most difficult to be determined but
if it happens (and it happened to me many times) it should be handled as
high priority. We can make (by discussing) exception to this "rule" on
special case where the fix is more urgent than having passing tests, but
in trunk I give much more importance to avoid to loose committers time
than to provide fast fixes.
I do completely agree on that. My main issue is committing tests that
fail not code that make tests fail.
My initial statement
"When there is a test failing we should treat it with the same priority
and thoroughness as issues in JIRA. If there are other things that are
more important or the solution is not clear it just stays there
failing."
was not meant as a free ticket for breaking existing functionality or
committing premature code. And I agree that it would need a discussion
to make an exception.
I just was relating to my impression that everyone started to search for
a quick solution with the priority to make the tests passing which ended
in commenting it out.
Joachim
1) Noel committed a patch with the idea to optimize code.
2) A test started failing but no one noticed it until an automatic build
failed.
3) We lost few minutes to understand why because we already had
sometimes the SMTPServerTest to randomly fail, so at first it was not
obvious it was something changed in the code.
4) After few more builds by my continuum I decided to open eclipse and
run the tests and I verified that the SMTPServerTest was no more passing.
5) I verified the behaviour of the test and "pinged" Noel about the
issue to notify him: I didn't have time to check what's going wrong.
6) He said it was probably the test to be wrong (It was also one of my
hipotesys) explaining why.
7) Noel had no time to look at it soon and other committers had in
progress works to finish before.
8) Both I and Norman rely on the automatic build by continuum to have a
further check on what we are committing, and in that timeframe we lost
more time than when tests passes.
9) Norman knew that Noel worked on that code and probably knew how to
fix it, so the best temporary solution was to comment out the test and
open a JIRA issue to be sure that Noel not forget the issue, or to be
sure that someone else could have assigned this issue to himself later.
This *is* what "started the flames". Imho it has been a good procedure
and I (by mistake) thought we all agree that tests have to pass before
committing and if they fail it is a mistake of the committer (to be
reverted or to be workarounded until fixed).
I have no more time for this issue. I think it is really a matter of
preferences, so if anyone thinks that failing tests should be accepted
and that another developer that find a unit test cannot comment it out
and open a JIRA issue to remember this to the committer that broke the
test, then please start a vote. It seems to me we already discussed too
much on this issue: it's time for decisions.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
