Saturday, March 3, 2007

Failing at TDD

Someone asked for more clarification about how I failed at TDD... I gave reasons why I failed, but no measurement of success. In the class, I had said that I failed until I finally changed my way of thinking and actually got what test driving is all about...

But I was thinking about this statement on the way home and this isn't true. Even after I understood how to test, my classes under test would outgrow their test fixtures because I wasn't in the habit of writing tests first or the tests were too rigid to change or I just wanted to get something to work really quick without having to write a test... a little extra code here and there eventually leads to a lot of failing tests, ignored tests, ignored assemblies and then total failure...

A few years ago I was lucky enough to have lunch with Bob Martin and we had a long talk about discipline. I would argue that this is the most important attribute for test development (he really knew what he was talking about, how little I knew then).

I finally considered myself successful in TDD when I had several projects that were test driven, and continued to evolve test driven as well... i.e. I was finally successful when my tests were refactored with the rest of my code, my tests continued to drive change and it wasn't painful.


nck said...

Hi, I heard several speakers mentioned about a software called "V# or VSharp". However I cannot google anything about it. I remember you also mentioned it once. Could you explain what it is? Thanks.

wunda said...

Maybe Resharper? If it was during the rhino mocks session, it was used a lot. I was trying to say all the shortcuts out loud, I hope I did an okay demonstration :)

nck said...

Thanks. You did a good speaking. It's my bad, I heard it of "Vsharp" when Chris Donnan mentioned it earlier in his speaking.

Anonymous said...

I was at your Rhino Mocks presentation and I was impressed with the product. Good job showing it.

I did want to ask your team a question though. How does your team set up your development tree for continuous integration?

I saw that your team used subversion and I assume you use Cruise Control .NET. This is the same set up that we use.

But my question isnt about the tools, its about the folder structure for each project. How do you guys set it up for Continuous Integration? I'm trying to find the best fit for my company, but the few ideas I've had have not worked out that well. If you could shed some light on how you set up your tree, I would appreciate it a ton!