I still slap my own hand, though.

There is, of course, a middle way. Implement as much testing as makes sense for you. Think Pareto.. just the right 20% of testing could give you 80% of the gains.

So.. implement integration tests that test your apps very broadly and as soon as one fails, you know you can start looking deeper. No need to always start with line by line unit tests :)

I prefer the approach we used here (at a non-startup). We simply decided that we were going to use automated tests as much as possible on a new project. Everyone was encouraged to use them. Our coverage wasn't 100%. However, when you are committed to creating an automated test case to reproduce any bug regardless of how the bug was originally found, your coverage expands. Usually you can write variants of the same test to cover related areas.

I can't speak for every member of the group, but my total testing time went down slightly and my test coverage improved enormously. Full TDD is not necessary in every instance. Just because you can't immediately make the jump to full TDD doesn't mean that automated unit test tools won't make your code better, and your testing easier.

The time you "lose" on the frontend of development is made up on the back.

You could do it even if you've never had an accident, many people do.

But most of the time you start doing it AFTER you go off the road once.

The asinine thing about this is that unit testing saves a massive amount of time in the long run. In the short run, even, it saves time.

You're really shooting yourself in the foot.

"...automated test suite saved the client 117 days of manual effort per testing cycle."

Sure, it takes more time to construct any given feature with unit tests versus a completely untested solution. However, any time you need to change the code, add a feature, or change something it interacts with, you are saving an incredible amount of time both in testing and the prevention of bugs discovered in production.

I really don't understand how, in the long run, automated testing can't save you time. If you don't think so, you obviously haven't maintained any software.

I think production code absolutely needs good test coverage, otherwise changing things is a nail biting affair.

Then when I start to integrate that solution into real production code I go back and add some tests. (mostly integration tests)

If it works it works, if it doesn't I do it again.

I don't think that's optimal, but that's the way it is, and due to time constraints a major refactoring of all the code I have running is not on my to-do list anytime soon.

Now on my next site (http://www.beepmystuff.com) I've got many unit tests and I'm much more confident when I make large changes.

The two site share a lot of code so the first is benefiting from the second getting a bit on TLC.

We have a quick set of unit tests that we run before very check in (10 seconds).

Next our CI kicks off after check in and runs 10 minutes worth of full system tests, booting up opensource software and running it against the system, destroying DBs and recreating them from scratch and running again, etc.

* Finally we have nightly test which run for a few hours, at this point we have 15 projects run against our system. We run projects over and over to test stability, we do security testing against the current code. We have multiple simulated users running against the system checking for performance bottle necks. This phase doesn't catch new issues that often, but helps us to assure we don't regress in performance, security, or overall compatibility support.

We also create tests to cover bugs to prevent regressions.

I still run "prove" before any new release though.

I've also experimented with Perl code coverage early on with good success. Again, time constraints prevent me from pursuing this further for now.

If you have the time, I would highly encourage writing some unit tests for the core functionality.

It's more fun that way. Instead of your code breaking when you add the test, it's broken until you add the functionality.

My code has many many tests. My co-workers would laugh at me, telling me I spent all my time writing tests. But if my code even RUNS, I'm confident that it is correct. I would get the last laugh, because my co-workers would always be doing frantic debugging right before a deadline because they just uncovered a silent bug.

I didn't always. I think a project has to grow past a certain size, to the point where you can't immediately remember what all the parts do, before the need for tests becomes painfully apparent.