If you are in the middle of a TDD iteration, how do you know which tests fail because the existing code is genuinely incorrect and which fail because either the test itself or the features haven't been implemented yet?  Please don't say, "you just don't care, because you have to fix both."  I'm ready to move past that mindset.
My general practice for writing tests is as follows:

First, I architect the general structure of the test suite, in whole or in part.  That is - I go through and write only the names of tests, reminding me of the features that I intend to implement.  I typically (at least in python) simply start with each testing having only one line: self.fail().  This way, I can ride a stream of consciousness through listing every feature I think I will want to test - say, 11 tests at a time.
Second, I pick one test and actually write the test logic.
Third, I run the test runner and see 11 failures - 10 that simply self.fail() and 1 that is a genuine AssertionError.
Fourth, I write the code that causes my test to pass.
Fifth, I run the test runner and see 1 pass and 10 failures.
Sixth, I go to step 2.

Ideally, instead of seeing tests in terms of passes, failures, and exceptions, I'd like to have a fourth possibility: NotImplemented.
What's the best practice here?
Most projects would have a hierarchy (e.g. project->package->module->class) and if you can selectively run tests for any item on any of the levels or if your report covers these parts in detail you can see the statuses quite clearly. Most of the time, when an entire package or class fails, it's because it hasn't been implemented.
Also, In many test frameworks you can disable individual test cases by removing annotation/decoration from or renaming a method/function that performs a test. This has the disadvantage of not showing you the implementation progress, though if you decide on a fixed and specific prefix you can probably grep that info out of your test source tree quite easily.
Having said that, I would welcome a test framework that does make this distinction and has NOT_IMPLEMENTED in addition to the more standard test case status codes like PASS, WARNING and FAILED. I guess some might have it.
TDD practice: Distinguishing between genuine failures and unimplemented features