Strategies for push/merge problem?

[Sean Russell]

On Wednesday 16 July 2008 04:16:25 am Adrian Buehlmann wrote:
> > One of the requirements for proper test-first development is ensuring
> > that the tests actually fail.  I can see a good use case for having that
> > in the history.
>
> Having a changeset in the official project repo that deliberately breaks
> the default global daily (hourly, or whatever) automatic build is plain
> silly (assuming the daily build runs the testsuite).

I think we're working on different assumptions.  I was suggesting that I might 
want to commit work that causes tests to fail to my local repository, and 
only push changes to the central repository when my work is complete and all 
tests pass.  This wouldn't have any affect on the periodic builds, at all.  
It *would* have an affect on bisecting, as you've pointed out earlier, but 
bisecting while running the entire test suite is useless to me.  At the 
project I'm working on, our test suite takes a half-hour to run.  It is much 
more efficient to bisect while looking for a particular, single, test 
failure.

> No one would ever want to run the project-wide full nightly build to verify
> that a specific unfinished-feature changeset breaks the testsuite.

Again, you're assuming that these commits would be shared before the final fix 
is in, and I'm saying that they wouldn't.

You later say:
> Ha! On second thought it's even simpler than that.
>
> If you create a test that is expected to fail, then the test is a negative
> one, which means that test is actually only successful iff and only if it
> fails. So the test *is* successful if it fails.

If you needed to, you could do this.  But it doesn't follow the test-first 
philosophy that tests are *supposed* to fail.  The whole point is to see a 
bunch of failures and *know* that they fail, and then work, work, work until 
they pass.  What you're suggesting is ginning them up so that they pass, and 
then you work, work, work until they fail.  This has psychological 
disadvantages.

In any case, I was just suggesting that there was a valid use case for having 
the fact that the tests did, indeed, at one point fail (as they should) in 
the history.  I didn't recommend it, but I can see a use for it.  For 
example, a company might have an audit trail policy that requires it.

--- SER