Between the research you discussed in your OP and the comments from other Monks, you have more than enough information at your disposal to begin to test the Perl way. But I want to call your attention to the fact that you described at least three separate problems in your OP -- problems that require additional reflection to solve.

The first problem is how to write tests with Perl. The other Monks have provided good advise, to which I would only add that, at a more advanced stage, learn how to conduct coverage analysis with Devel::Cover.

Second, "most of us are self taught, or have only the haziest ideas about Object Oriented Programming, or writing/ using modules at all." Note that this is a problem distinct from the learning-how-to-write-tests problem.

Third, "I’m also going to touch on Perl Tidy and Perl Critic, as ways for us to enforce these coding standards weÂ’re agreeing on." Again, this is a problem distinct from testing.

I would recommend thinking about:

1. Are the developers in my company ready to tackle these three problems simultaneously? If not, how should you arrange your priorities?
2. Can I effectively proselytize for testing, modularized programming and code standards all at once? If not, at which can I be most effective? Are there other developers who would be more effective advocates for one of the projects than I would be?
3. If I am writing tests for already existing code, what happens when my tests begin to suggest that the code ought to be restructured to a greater or less degree? How will the author or current maintainer of that code react? What procedure does your company have set up to handle disagreements as to how code should be structured?

As you can see, these are not Perl questions or testing questions; they are human relations questions. Tests can't change suboptimal code; only humans can. Lest you bite off more than one person can chew, I recommend that you think about these questions a bit, then figure out the best role for you yourself to play.