Scott Hanselman

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.

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!

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?

@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

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

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...