moshe: > > The XP answer would be "hey, you have to checkin the breaking > > test case right away", and I'm inclined to agree. tim: > It's abhorrent to me to ever leave the tree in a state where a test is > "expected to fail". If it's left in a failing state for a brief = period, at > best other developers will waste time wondering whether it's due to > something they did note that we've just seen this in action, in the SRE crash thread. Andrew checked in a test that caused the test suite to bomb, and sent me and Mark F. looking for an non-existing portability bug... > You can check in an anti-test right away, though: a test that passes = so > long as the code remains broken <wink>. which is what the new SRE test script does -- the day SRE supports unlimited recursion (soon), the test script will complain... </F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4