We have been running the Coder´s Dojo Sweden during the autumn, and yesterday we started the spring sessions. One of the interesting observations that we have made is a follow-up on a comment that I made on Robert C. Martins page about the Bowling Kata.
The observation was that if you follow the rules “refactor only in the green” (you may only refactor while you have working and passing tests as your life-west) and “only develop new functionality in the red” (while you have a failing test for that functionality), you will inevitably end up with a situation that your new functionality driving test case forces a re-design, right?
It may be obvious to most of you out there, but we couldn’t find a single mention of how you are supposed to solve that predicament. We surely do not want to do a redesign with a failing test, the green bar is our safety net. Of course you could keep an eye on which tests are causing the red, but that is tedious and error-prone.
What seems logical is to temporarily get rid of the failing test, which you can easily do by commenting out the failing test. Simple, right? And possibly second nature to seasoned TDD:ers. But if so, why has there been no developmen of tools support for this? I could easy envision a “disable test” feature in the Eclipse/JUnit GUI…
Thomas Nilefalk on Responsive Development of Software, Systems and Organizations