The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code

Test::Inline?

You also might find the idea of Zero Button Testing appealing.

Personally, I find having the code and the tests in the same document gets in the way of reading the code and interferes with refactoring, but YMMV.

You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.

Doctor, it hurts when I do that :-)

In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.

I see people asking for this sort of functionality a lot and it confuses me. I must be misunderstanding what you mean since, on the face of it, what you're requesting seems to be impossible. How would the magic test producer know what the code should do.

Design by contract shows great potential (IMO)

Interestingly enough DBC used to be my preferred design methodology, before I discovered TDD (Eiffel is still one of my favourite languages). Because you're dealing with concrete data rather than an abstract contract I find it much easier to incrementally develop code with tests.