Comments on: Some Pitfalls Of Test Driven Development http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/ Lidor Wyssocky's Blog on Optimizing Software Development Thu, 28 Aug 2008 12:22:24 +0000 http://wordpress.org/?v=1.5.2 Comment on Some Pitfalls Of Test Driven Development by: Dave Nicolette http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-1245 Fri, 11 Aug 2006 14:13:20 +0000 http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-1245 Lidor, If you can teach developers to write good code to start with, and they habitually use TDD, then their projects will enjoy the benefits of both. TDD is not a substitute for knowledgeable software engineering. It's a technique for building clean, well-tested code and for paying off design debt incrementally. Planning to refactor deliberately is not an error, and not an indication of poor initial design or code. No one writes "bad code" on purpose "just" to make a test pass. It is natural for a codebase to become messy as functionality is added to it. Incremental refactoring as part of the red-green-refactor cycle is a way to keep the codebase clean as that occurs. TDD is an evolving discipline, and not a static practice. Presently, two areas of improvement that are gaining traction are (a) behavior-driven development and (b) refactoring to patterns. The former requires developers to think, design, and act as business analysts before writing anything. That leads to well-considered, clean designs that accurately reflect requirements, and to tests that reliably demonstrate that requirements have been met. The latter combines pattern-based design, recognition of code smells, and sound software engineering practices with TDD's red-green-refactor cycle. That leads to high-quality, maintainable code with few defects. It isn't a question of whether TDD works "for you," it's a question of whether TDD works "for software development." It does. If TDD doesn't work "for you," you will find the reason in the mirror. Your blog is all about optimizing software development. TDD is one of the most effective tools for doing so. It's all the more powerful in the hands of knowledgeable, highly-skilled developers. By treating TDD as if it were merely a workaround for ignorant or careless developers, you may be overlooking or undervaluing a very useful and practical tool for optimizing our work. Be careful not to get carried away by the anti-agile "backlash" people are talking about these days, and forget your own goals. ;-) Lidor,

If you can teach developers to write good code to start with, and they habitually use TDD, then their projects will enjoy the benefits of both. TDD is not a substitute for knowledgeable software engineering. It’s a technique for building clean, well-tested code and for paying off design debt incrementally.

Planning to refactor deliberately is not an error, and not an indication of poor initial design or code. No one writes “bad code” on purpose “just” to make a test pass. It is natural for a codebase to become messy as functionality is added to it. Incremental refactoring as part of the red-green-refactor cycle is a way to keep the codebase clean as that occurs.

TDD is an evolving discipline, and not a static practice. Presently, two areas of improvement that are gaining traction are (a) behavior-driven development and (b) refactoring to patterns. The former requires developers to think, design, and act as business analysts before writing anything. That leads to well-considered, clean designs that accurately reflect requirements, and to tests that reliably demonstrate that requirements have been met. The latter combines pattern-based design, recognition of code smells, and sound software engineering practices with TDD’s red-green-refactor cycle. That leads to high-quality, maintainable code with few defects.

It isn’t a question of whether TDD works “for you,” it’s a question of whether TDD works “for software development.” It does. If TDD doesn’t work “for you,” you will find the reason in the mirror.

Your blog is all about optimizing software development. TDD is one of the most effective tools for doing so. It’s all the more powerful in the hands of knowledgeable, highly-skilled developers. By treating TDD as if it were merely a workaround for ignorant or careless developers, you may be overlooking or undervaluing a very useful and practical tool for optimizing our work. Be careful not to get carried away by the anti-agile “backlash” people are talking about these days, and forget your own goals. ;-)

]]> Comment on Some Pitfalls Of Test Driven Development by: Sunitha Patel http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-737 Mon, 26 Jun 2006 14:39:26 +0000 http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-737 I really like your blog, you've got great stuff in here! :) I'm just a beginner in TDD myself and trying to incorporate it in my work now. I read another blog with a post on TDD that explains the reason for first making the test fail and then making it pass. It really made me understand the reason for this process. This site also has quite a few good blogs on this topic, in case you or your readers are interested. Here's the link: http://codebetter.com/blogs/scott.bellware/archive/2005/11/22/134954.aspx It really showed me the light with the ideas of TDD. From all I've read so far about it (which has mostly been from blogs like these), it seems to be a great design methodology - if done right! Isn't that always the hardest part? I guess it's something like how you talk about the hijacking of the word "Agile"! Thank you again for all the posts, I enjoy reading them! I really like your blog, you’ve got great stuff in here! :)

I’m just a beginner in TDD myself and trying to incorporate it in my work now. I read another blog with a post on TDD that explains the reason for first making the test fail and then making it pass. It really made me understand the reason for this process. This site also has quite a few good blogs on this topic, in case you or your readers are interested. Here’s the link:

http://codebetter.com/blogs/scott.bellware/archive/2005/11/22/134954.aspx

It really showed me the light with the ideas of TDD. From all I’ve read so far about it (which has mostly been from blogs like these), it seems to be a great design methodology - if done right! Isn’t that always the hardest part? I guess it’s something like how you talk about the hijacking of the word “Agile”!

Thank you again for all the posts, I enjoy reading them!

]]> Comment on Some Pitfalls Of Test Driven Development by: Lidor Wyssocky http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-16 Wed, 29 Mar 2006 00:00:28 +0000 http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-16 I agree that for some developers writing good code to start with is not the most economic way... yet. If you can teach these developers to write good code to start with (or create good designs for that matter) you will achieve higher optimization of their work: more value for less cost. This is not only possible, but even essential in order to reduce development costs. I agree that for some developers writing good code to start with is not the most economic way… yet. If you can teach these developers to write good code to start with (or create good designs for that matter) you will achieve higher optimization of their work: more value for less cost. This is not only possible, but even essential in order to reduce development costs.

]]> Comment on Some Pitfalls Of Test Driven Development by: Jürgen Ahting http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-14 Tue, 28 Mar 2006 20:41:27 +0000 http://blog.qualityaspect.com/2006/03/25/some-pitfalls-of-test-driven-development/#comment-14 While I can almost agree with your "Bottom Line", I don't agree with the section "Caution! Rework Ahead.". Test "Driven" Development simply means that the thinking goes into the tests not the code. It's the quality and sequencing of creating and changing the tests which induces the initial quality of the code. If we have a "grand plan" for good code in mind nobody prevents us to write and change the tests in such a sequence that we are forced to produce exactly the code we have in mind. Whether that is the most economical way is probably different for every programmer. While I can almost agree with your “Bottom Line”, I don’t agree with the section “Caution! Rework Ahead.”.
Test “Driven” Development simply means that the thinking goes into the tests not the code. It’s the quality and sequencing of creating and changing the tests which induces the initial quality of the code. If we have a “grand plan” for good code in mind nobody prevents us to write and change the tests in such a sequence that we are forced to produce exactly the code we have in mind. Whether that is the most economical way is probably different for every programmer.

]]>