in reply to Testing 1...2...3...

I was programming for a quarter-century before I actually sat down and built acceptance-tests while I was writing code.   And the experience really startled me.   It took a lot more time, and it took a lot less time.   The difference was startling.

I admit it:   I hate to test my work.   “If it compiles clean, I’m done.”   I still have to force myself to do more.

There is a tradeoff to be struck.   There are no absolutes.   You cannot test everything, nor do you necessarily have to.   What seems to matter the most are the low-level primitives ... the stuff upon which everything else in the program’s whole world depends.   It is easy to redo a piece of sheetrock, but if the house has foundation problems it may as well be torn down.

But, yes, it is a mark of a good, healthy program-development culture that folks do test as they build.   (For one thing, it suggests that they have given some thought to what they are actually doing|going to do.)   What CPAN routinely does is a good example.

Replies are listed 'Best First'.
Re^2: Testing 1...2...3...
by mpeever (Friar) on Dec 09, 2010 at 20:36 UTC

    I've developed a similar take on test coverage. We test "library" code heavily with Test::More (mainly integration tests, some unit tests). The utilities and apps we write that call them are tested much more casually. We're a small team, and we find the balance to be reasonable for our environment.

    We have been disciplined about writing first the POD, then the tests, then the code. I've had the luxury of a fairly inexperienced guy on the team, so I've not been having to fight years of experience, at least with him... The poor guy thinks this is normal.

    I've said it before, but I have found the single biggest payoff---even more than writing tests---has been a disciplined approach to consistent POD. Consistently testing has been probably the second most significant gain.