TDD: Start With A Failing Test

The question was asked:

In Test-Driven Development, what does it mean to start with a failing test? 

This is not a complicated question, so let me give the short answer:

• Write a test that can't possibly succeed because you have not yet implemented the feature; but which would succeed if the part of the feature it's testing were written.
• You want it to be a good test: clear, obvious, simple, discrete.
• You want it to fail, so you see what the error message will look like -- whether it will provide enough information when someday it fails unexpectedly.
• Then you write enough feature that the test passes works (but not the whole feature).

The idea is like a video game. You write a test, which is your first challenge. Then you beat that challenge and save your game (to version control) so you can come back. You layer on the challenges until you've beat the game (written the feature).

There is more to the TDD cycle, but this is enough to answer the one question.

BTW, the same "accumulation of phases that work" is the preferred approach to writing stories, which add to features... the whole world of test-driven is about thin, tested, integrated slices continually being built and integrated.