Strategies for push/merge problem?

[Adrian Buehlmann]

On 16.07.2008 14:08, Peter Arrenbrecht wrote:
> On Wed, Jul 16, 2008 at 1:29 PM, Peter Arrenbrecht
> <peter.arrenbrecht at gmail.com> wrote:
>> On Wed, Jul 16, 2008 at 10:31 AM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>>> 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.
>> Now this I find a very interesting thought.
> 
> We once tweaked a particular testing framework so we could have pass,
> fail, and /known but for the moment accepted bug/. This latter one
> seems appropriate for such test-first commits, too.

Yep.

And this could be done without touching the original test by
adding a layer like an inversion list or something (or add a
file 'test-jingles-at-5pm.invert' for the 'test-jingles-at-5pm'
test and remove that as soon as it is expected to first jingle).

Also if there's a testsuite breakage detected (that nice morning, you know)
and there's still someone left in the "enterprise" who volunteers to go
bisecting for the offending cset:

Suites usually break on a few specific tests or even just a single one
(if the tests are orthogonal enough).

That single test can then be picked as a litmus test
in the bisect iterations (no need to run the whole testsuite
on each bisect iteration).

But I'll try to shut up now :-)