People have been pointing out how TCR does not support the red test step of TDD. In TDD you begin with writing a test that does not pass. If you make a test that does not pass in TCR, you lose the test you just wrote.
I have seen various suggested solutions to this. Some would have their TCR script never revert test code – only implementation code. This strikes me as complicated. And it feels wrong to hold test code to a lower standard than implementation code.
I have also seen suggestions where the TCR flow would have different states, where you would not revert if you are in a red state. This sounds like regular TDD and only applying TCR to the refactoring step. Which seems pretty reasonable, but it is not what I want to do.
Instead of changing how I revert, I am changing how I fail. I want to write a red test that fails, but does not cause any reverting to happen.
I have done this in Elixir, but I assume you can do similar things with other languages. I
@tag my red test with
This does not change anything by itself, but allows me to exclude the test from the T in my TCR script:
This makes the failing of the red test a safe move, but it does not protect the test (or any other code) from being reverted by an actual failure.
I still want the feedback from the failing red test, so after the TCR steps, I run the pending test alone:
I end up with something like this:
Got any thoughts on this? Bark at me on Twitter