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?
I also now realize that the unittest.expectedFailure decorator accomplishes functionality congruent with my needs.  I had always thought that this decorator was more for tests that require certain environmental conditions that might not exist in the production environment where the test is being run, but it actually makes sense in this scenario too.
TDD practice: Distinguishing between genuine failures and unimplemented features