I disagree. We spend a considerable amount of time writing our behavioural tests (we have around 1,700 for our large web app), but they have saved us countless times from having to track down bugs after deploying code.

There was an article published in the last few weeks which showed that teams who write tests spend 10-15% longer in the development process, but they also save 25-30% of the development process time by not having to fix regression defects. Unfortunately, I don't remember which site it was linked from or what the article's title was. If I can find it, I'll link it here.

I have to agree with Jon. Really, once you get into the cycle, and you write them first, it doesn't tend to add much time. It does, however, really hurt your productivity when you start doing TDD. It's akin to the hit you take when you move to a new programming language. You'll feel faster if you don't do it. But as you get more comfortable and get into a rhythm, it can be fairly insignificant. Just don't get ahead of yourself, and don't let the tests get out of sync.

Rails is a good example where this sync stuff is hard. It's wicked easy to use things like associations and named scopes to query records while forgetting to write a test to ensure that those queries actually return what you specify.

But keep in mind that tests aren't just for you. They're for your team, and the next guy who follows you. You can learn a lot about intent from tests too.