On Friday 19 October 2007 11:37:08 Bernhard Schmalhofer wrote:

> chromatic schrieb:

> > For two, allowing known failing bugs is the Broken Windows anti-pattern. 
> > Not only does it undermine confidence in the software (oh, still broken!)
> > but it adds noise that makes it far more difficult to know if a change
> > introduced a new bug (which tests were failing?  1, 3, and... oh forget
> > it!)

> Would Smolder address the question: Which tests were introduced by my
> last change ?

Perhaps.

> I am missing here the distinction between:
> A) There is an unimplemented feature so I add TODO tests for that
> B) This feature should be working, but it isn't.
> C) It is known what the problem is, it just isn't fixed yet

The distinction is between:

A) My most recent change did not break anything (all tests pass)
B) My most recent change broke something (some tests failed)

Any failing tests that stay failing for more than a checkin or two break that 
model.  Yes, that includes the two or three remaining failures from the PDD 
15 merge back, and yes we should TODO those.  Allison is working on them, so 
she knows what they are and can unTODO them when she fixes them.

-- c

Reply via email to