The tests of a module provide good clues as to how to use the module, but one has to realise that some of those tests may be there to see how the modules deals with incorrect usages. There may be lots of obscure corner case tests designed to achieve a high level of code coverage.

Sometimes it can be hard to spot what is essential.

Real examples are better in that there's none of the test infrastructure, or the test suite's goals, getting in the way. You can take one and then start to bend it into shape to solve your own task. This is my usual approach to HTML::Parser, since I don't use it enough to remember all of the API. Having a usable skeleton is a great way to start hanging lumps of flesh off it :)

Also, as far as conventions and standards regarding modules goes, if it isn't discussed on the module-authors mailing list, it will become neither. This is not to dismiss Perlmonks, but these things tend to get thrashed out over there. People sometimes don't realise that a lot of the Perl community doesn't hang out on Perlmonks.