Version control and test-driven development

Question

The standard process for test-driven development seems to be to add a test, see it fail, write production code, see the test pass, refactor, and check it all into source control.

Is there anything that allows you to check out revision x of the test code, and revision x-1 of the production code, and see that the tests you've written in revision x fail? (I'd be interested in any language and source control system, but I use ruby and git)

There may be circumstances where you might add tests that already pass, but they'd be more verification than development.

Answer 1

A couple of things:

1. After refactoring the test, you run the test again
2. Then, you refactor the code, then run the test again
3. Then, you don't have to check in right away, but you could

In TDD, there is no purpose in adding a test that passes. It's a waste of time. I've been tempted to do this in order to increase code coverage, but that code should have been covered by tests which actually failed first.

If the test doesn't fail first, then you don't know if the code you then add fixes the problem, and you don't know if the test actually tests anything. It's no longer a test - it's just some code that may or may not test anything.

Answer 2

Simply keep your tests and code in seperate directories, and then you can check out one version of the tests and another of the code.

That being said, in a multi-developer environment you generally don't want to be checking in code where the tests fail.

I would also question the motivation for doing this? If it is to "enforce" the failing test first, then I would point you to this comment from the father of (the promotion of) TDD.