Scott Hanselman

Hanselminutes Podcast 146 - Test Driven Development is Design - The Last Word on TDD

January 17, 2009 Comment on this post [6] Posted in Podcast
Sponsored By

imageThe one-hundred-and-forty-sixth podcast is up. Scott Hanselman talks to Scott Bellware about TDD. ScottB says that Test Driven Development is less about Testing and more about Design. Is TDD poorly named? Did Test Smell beget Design Smell beget Code Smell? ScottB has the Last Word.

Subscribe: Subscribe to Hanselminutes Subscribe to my Podcast in iTunes

Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Telerik is our sponsor for this show!

Building quality software is never easy. It requires skills and imagination. We cannot promise to improve your skills, but when it comes to User Interface, we can provide the building blocks to take your application a step closer to your imagination. Explore the leading UI suites for ASP.NET and Windows Forms. Enjoy the versatility of our new-generation Reporting Tool. Dive into our online community. Visit www.telerik.com.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
January 17, 2009 8:54
Sorry Scott. Your "Play in your browser" link points to the previous show. Also is there anyway that you could use the media enclosure to your feed to allow people consuming this with external readers (Google Reader) to listen to your podcasts directly? You stay classy.
January 17, 2009 14:51
This podcast finally made sense enough of TDD. Now I'm working on learning to applying TDD to my day-to-day programming. In fact, I blogged a little bit about this...

Thanks Scott!
Ben
January 20, 2009 20:32
Great episode, Scott, and it was an eye opener. I learned that I have a lot of test friction, where I am spinning up objects to go and do some database work, and then testing whether that db write was successful. I am hearing in this episode that my approach is wrong, and I am incurring way too much friction.

Does anyone have any favorite resources to help educate someone like me who wants to leverage unit tests in, for example, a CRUD app?
January 22, 2009 19:44
@Philoushka

Check out http://www.autumnofagile.net Steve Boheln demonstrates a DBUnit test class that sets up your database, runs your tests and then reverts back to it's original state during the test teardown...makes it really easy to run DB dependent tests.

Ryan
January 26, 2009 20:27
In an Intro to TDD talk I give (CodeCamp download at http://chippewavalleycodecamp.com/Downloads/tabid/60/Default.aspx), I present this same concept. See "TDD is not about testing" on slide 6.

The best way I get an audience to grok this concept is my story about an immediate "second consumer." In other words, the TDD unit tests immediately provide a second consumer of the code I am writing. This contributes to loose-coupling and independent-design. So by using TDD, I am "designing" my software and I am prevented from putting too much burden on the callers simply by writing the TDD unit tests first.

Another controversial stance I take is that TDD can be a productivity improvement. Even most TDD advocates will offer that TDD may take longer, but the improved results are worth it. I argue that TDD always provides me with "motion" in the form of writing a failing test. This motion prevents paralysis and leads to increased productivity.

Tom
February 10, 2009 1:18
I found the show rather frustrating... mostly because I'm not sure if my design meets or does not meet the small object idea/ SRP. The show was big on the idea and what people are getting wrong... but lacks specifics... regarding my on design, I *think* it is properly sized, but some of the comments about database testing left me wondering if maybe I'm delusional about my own patterns.

I guess I'm struggling with the idea of test friction in terms of the database tests. So if I have a DAL layer that has a single responsiblity: CRUD (no validation or other stuff in it) how can I test it w/o doing some sort of test prep/teardown? now that test prep/teardown may be some other class library that does it magic for me... but isn't that just defering the smell elsewhere? I don't see how you could possibly make your DAL tests not need some way to pre/post prep the database....

So a previous poster talked about a code library that does the DB setup/teardown... but (and I'm ignorent of the library so maybe it's handle magically somehow) don't you have to tell that object what to setup/KP??? and isn't that more test friction to understand that objects behavior?

Maybe I'm just not getting it...

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.