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 :pending.

@tag :pending
test "red test" do
  assert 1 == 2

This does not change anything by itself, but allows me to exclude the test from the T in my TCR script:

mix test --exclude pending

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:

mix test --only pending

I end up with something like this:

mix test --exclude pending \
&& git commit -am $1 \
|| git reset --hard \
; mix test --only pending

Got any thoughts on this? Bark at me on Twitter