In TDD, what is the advantage of running the tests before even writing an empty method?

Question

I see lots of TDD practitioners following this cycle:

1) Write your test as if the target objects and API already exists.

2) Compile the solution and see it break.

3) Write just enough code to get it to compile.

4) Run the test and see if fail.

5) Write just enough code to get it to pass.

6) Run the test and see it pass

7) Refactor

What is the advantage of steps 1 and 2? With IDEs like Visual Studio this is really annoying to do, since intellisense jumps all over the place trying to guess methods and attributes that are not there.

I usually start on step 3, having all my methods throwing NotImplementedException, and this seems perfectly fine for me, but maybe I am missing something.

Edit for clarification: this is not a question why I should see a test fail before it passes; that is covered on step 3 onwards, and it makes total sense. My question is why even before that people will call a method on the unit test that doesn't exist in the API (therefore VS will show a red squiggle, or paint the whole method name red etc) and try to compile anyway. For me the fact that VS is telling me that the method does not exist is good enough.

Answer 1

Then try it by writing the method name first. I find by writing the test first and the methods, it forces me to really think about the API, and I'm free to easily change names without having to worry about code that has already been written. My suggestion would be to try not following the rules, and monitor what happens. If you find that it causes problems, switch back. And if it doesn't, you've got a new way of working now.

Remember also that when you are first learning about things, generally you need a clear set of rules to give you context. As you begin to move from Beginner to more advanced, you'll gain more context and be able to make tweaks. It sounds to me like that's where you are.