Jim Shore and Shane Warden have a good description in “The Art of Agile Development”. They have the steps of TDD as:

Think
Write a test and watch if fail
Make the test pass
Refactor
Repeat

You do a little bit of design immediately before you write a test, and improve the whole design once your test is passing. I use TDD all the time, because it helps me to design my applications better, and ensure that what I’ve done actually works. If I need to change my mind about something, it’s easy to remove the tests that don’t apply any more and then develop new code and write new tests (using TDD) for how it’s now supposed to work.

Throwing away test suites is no worse than throwing away code.

By no means did I want to disparage TDD. If you’re the type of developer who can write a detailed spec and then code it top to bottom, then it may make a lot of sense to write the tests upfront. But I have to work in a more iterative way, and I’ve had to throw away whole test suites when it became clear that I’d written code that did the wrong thing, perfectly.

Because it allows abstraction on axes that simply aren’t possible in C#, and I’d rather spend my time building more powerful tools and libraries than trying to figure out how to work around C#’s intentional limitations. Your analogy is backwards here: if everybody else is running the Kentucky Derby with a camel, would you use one too?

“The problem with a lot of the most powerful tools is that you can adapt them to your problem. But it will take so much time and deplete so much of your sanity that you would have been better off just holding your nose and using C#.”

I don’t see the connection here. How would using more powerful tools deplete your sanity? And aren’t camels the smelly ones?

“Test Driven Development is like Grammar Driven Literature.”

Bad analogies are like thunderstorms.

“The great thing about tests is that they freeze your functionality in time. But that’s the last thing to do if you expect to make major architectural changes (and you should).”

If you’re making major architectural (or any other) changes, you do want to freeze functionality: everything except what you’re changing right now.

“Instead, wait to create your tests, style your pages, and document your code until after you have the whole application roughed in. Otherwise you risk spending a lot of time on code that you end up throwing away.”

Yes, that would be awful. It would be like a doctor spending a lot of time on a patient who’s going to die anyway.

A simple or rarely changing feature may not need any automated tests after you initially verify it works manually. In other cases, the process may require alot of time to manually verify, or may require continual manual testing as the app evolves, so an automated test may be warranted.

When in doubt I tend to write the tests, and evolve them with the feature, knowing in some cases I may need to throw out some testing code, which is fine, because at least overall I’m making the best use of my time.

I have a love/hate relationship with TDD, so depending on the day of the week, I may totally agree with this or totally disagree with it. Either way, it’s an amazing turn of phrase! You’re a poet. Awesome.

You (the author) are simply unclear on the concept. TDD does not freeze your architecture; in fact, it does the opposite. It gives you the confidence (not just a gleam in your eye, but real, mechanized proof) that even huge changes done at any step in the project can be done without hesitation and with minimized risk. This is why TDD is a cornerstone of agility.

There are other misunderstandings about TDD that you probably also have if you didn’t get that one, but I think that’s the most important one.

And there’s a difference between changing functionality and changing architecture. In fact if you want to change the architecture but keep the functionality you’re really really going to want to have those tests.

I would suggest that you have a good set of user interaction stories that encompass the application you are creating – particularly stories that flex the edge cases, and create tests (or test scripts) for those. Having a set of “sanity tests” that were created around the idea will be invaluable when you are racing to meet a deadline and have been so mired in details that you may have lost your sense of direction.

The right time for TDD is right now. *Especially* if you expect to have major changes coming in.

Your tests need to be written at the right level, to be testing the right stuff, but diving into a major project nowadays without writing robust tests as you go along is just really bad practice that will really, really hurt you not in the long or medium term but even next week – long before you release your beta.

If you do major refactorings, certainly some of your tests will break. And there, the difference between having tests and not having tests will be the difference between knowing what actually broke in this refactoring and not knowing. That can make the difference between that refactoring taking an afternoon or it taking two weeks of trial-and-error.

TDD, like many agile practices, is especially useful when there’s a lot of change ahead. Don’t skimp on it.

Daniel

PS: By “TDD” I mean writing automated tests, generally up front, before writing code. Quite acceptable to work out a bit of code without writing tests immediately if it’s quite complex and you need to figure out how to do it first, but the tests shouldn’t be far behind.

@Louis – It *is* tough to stay focused, because learning new things is half the fun of development. (At least for me). And personally, I tend to start little technical “side quests” when I’m trying to avoid something harder (like marketing). I guess we all just have to learn to work around our own bad habits.

I will also emphasize your point about having beta testers. Getting beta testers early is a good thing not only for the great ideas they can provide, but it helps a lot in keeping the motivation, and remaining focused.

That’s 4 months I didn’t work on my program. Although my website did need a new design, my blog and forum were doing the job they were meant to.