Strategies for push/merge problem?

[Adrian Buehlmann]

On 16.07.2008 10:16, Adrian Buehlmann wrote:
> On 16.07.2008 04:03, Sean Russell wrote:
>> On Tuesday 15 July 2008 11:12:09 am Adrian Buehlmann wrote:
>>>>> "Cheap" commits doesn't mean they are allowed to be brain damaged.
>>>> Sure it does. I practice test first design, so I commit tests that
>>>> break because the code isn't there yet.
>>> Well, there's no need to commit that. But obviously we have different
>>> mindsets. You seem to argue that "test first design" implies committing
>>> testsuite breaking changes. It doesn't.
>>>
>>> I wouldn't pull such a patch of yours into any repo I would be
>>> responsible for.
>>>
>>> Why would anyone else need your breaking test *enabled* in the
>>> testsuite without the code?
>> 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).
> 
> No one would ever want to run the project-wide full nightly build to verify that
> a specific unfinished-feature changeset breaks the testsuite.
> 
> Such known-to-fail tests would have to be marked as such and be *disabled* in the
> default global test suite configuration and only run individually during
> development of specific features on specific request or with an explicit option
> to run the full testsuite *with* all these tests enabled.
> 
> Ensure that all tests which are made to fail are by default disabled in the
> testsuite and thus the nightly build.
> 
> This should be upheld for every single changeset.
> 
> Then you have upheld the invariant that every cset should pass the
> testsuite and you can use that invariant when bisecting.

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.

As soon as you have finished your feature, your expectation about that
test changes. You then expect that test to pass. Then you have to change
that test into a positive one. Do that in the same cset in which you
expect your new feature to pass your test and you have upheld the invariant.