Tim's .NET Software Architecture Blog

Adventures in Architecting and Developing .NET Applications


News

Technorati Profile

Listed on BlogShares

My Stats

  • Posts - 157
  • Comments - 59
  • Trackbacks - 57

Tag Cloud


Recent Comments


Recent Posts


Archives


Post Categories


Image Galleries


Blogs


Link Blogs


Links


Podcasts



Rocky Lhotka was recently on DNR and made some comments about TDD that have created quite a stir.  Rocky has posted a deeper explanation of his comments from the show.

I first must place myself as a TDD skeptic who finds the topic worthy of more research.  Personally, I have many of the same concerns that Rocky brought up.  Much of what I have read on the subject focuses on building one piece of functionality at a time.  I try to keep an open mind, and maybe I am missing something, but it seems that this narrow focus would lead to code that does not play well with others and a lot of rework.

I think people need to remember that no matter how much you believe in your approach others are going to disagree with you.  Saying or implying that a person is irresponsible because their viewpoint differs to me is the sign of a closed mind.


posted @ Friday, March 31, 2006 2:00 PM | Filed Under [ Rant ]

Comments

Gravatar # re: A TDD Holy War
Posted by Jeffrey Palermo on 3/31/2006 4:49 PM
I completely agree with you. All good points.

There are few absolutes in software development.

TDD (and other) zealots give all TDD practitioners a bad name. I'm TDD practitioner, and I like what it has done for me, but TDD "purists" would probably disapprove of my practice of TDD because I don't test drive simple property accessors, for instance. It all comes down to good judgment.


Gravatar # TDD Misconceptions
Posted by on 3/31/2006 6:39 PM
TDD Misconceptions
Gravatar # re: A TDD Holy War
Posted by Gregory A. Beamer on 7/19/2006 7:24 PM
TDD is a tool. I find that it can be a highly effective tool. It DOES NOT replace QA testing, acceptance testing, yada, yada. If you are going to implement TDD, you should cover all code as a minimum. You should also cover every bug with a test to confirm it.

TDD can provide a start for more thorough QA Testing, Regression testing, etc. And, when implemented properly, it gives a higher degree of confidence in code quality.

Having said that, I am not a purist. I like VS 2005's method of designing classes first and then extracting tests. I find that I have to dupe for failure conditions, etc., but it certainly speeds up my TDD efforts over the purist "write ALL tests first" method. Am I denigrating the purist method? Certainly not, as I feel it has value; I am just too lazy to work that hard for the value now that the tool allows me short cuts. :-)
Post a comment





 

Please add 1 and 4 and type the answer here: