通过

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.

Comments

  • Anonymous
    March 20, 2004
    How do i write tests for the following :

    1) GUI, how to test if a control paints incorrectly, flickers or has inconsistent behaviour ?
    2) DB stuff, test is possible but i have to repro every possible combination of data, testing this might take ages
    3) Heuristics, where what is wrong or right is subjective
  • Anonymous
    March 20, 2004
    The comment has been removed
  • Anonymous
    May 14, 2004
    ji i want to known answer for you
  • Anonymous
    May 15, 2004
    Huh?