Edit & Continue vs. Test-Driven Development

When you do TDD, your code takes on a very different structure than without TDD.  Each line of code is motivated & tested by a test.  Code is decoupled, just like my Computer Science profs used to talk about.  You may not write the correct piece of software, but you can be confident you wrote what you intended to write.

If you have a bug, you can isolate it with TDD, too.  Form a hypothesis about that cause of the bug, add a test to test your hypothis, and repeat until your assumptions are verified in good unit tests.  When you write this way, classes & methods tend to be small and simple. 

Private methods are less pervasive than non-TDD code, as private functionality gets factored out into new classes.  This is necessary to make TDD a reasonable venture: the tests typically only have direct access to the publics.  (It's also typically a better OO design, relying on classes more than functions.)

You now have a situation where a simple unit test is only a couple function calls away from any bug.  Compare to the Einstien case I mentioned earlier, and you'll see that complex repro scenarios are comparitively rare.  You can reproduce the faliure in seconds - just run the unit tests.

When that cycle is so short, E&C doesn't help nearly as much. 

I want to make it clear that I recognize that E&C is still valuable for TDD users, and that a large portion of C# users aren't doing TDD.