"When eating an elephant, take one bite at a time."

Another approach is simply to commit yourself to adding (at least) one test a day to the test suite. Picking the low-hanging fruit is perfectly acceptable - does the module load without error? Do I have all the methods I expected to have? If the module exports symbols, do I have them? If the Pod says this call dies, does it?

You can actually add a lot of value with tests like these (e.g.: someone accidentally leaves out a =cut, thereby commenting out a swath of methods - the "do I have all my methods" test will catch this. Syntax errors in the code? The "does my module load" test catches those before you commit to the repository.

As mentioned, adding a test for each new bug (illustrate the wrong behavior happens/the right behavior doesn't, then test for the right answer), add a test for each change you make (the code should now do this) will all help build a test suite dynamically.

Feel free to put in TODO tests that simply fail for the moment:

TODO: {
    local $TODO = "Test not yet implemented";
    fail "Missing a test for X";
}
[download]

This will "pass" as a TODO test and remind you that you wanted to test feature X later. You can then go back and add a failing test for X; when you finally fix (or implement) X, you'll get an UNEXPECTEDLY SUCCEEDED and can go back and remove the TODO wrapper from the test.

Anything you run to check your code, or see a peer run, is a potential test. Just look for a way for a program to automate it -WWW::Mechanize for web checks, Expect for command-line programs, and so on.

You are absolutely right: testing will make your life easier. If you need to justify developing tests, keep a log of the amount of time you spend writing tests, and then for each test, keep a count of how many times that test finds an error for you. You may be surprised (and your peers/management may be very surprised) how quickly those add up!

Remember: a little testing is better than no testing at all.