If would be my view that you personally should have unit tests for everything that is important to your system. If you subclass I would suggest you should

1. First look at the code and the tests of the superclass (you are afterall throwing you hat in with it)
2. Steal every last one of its tests, making only such modifications as are required to get them to run

Why 'steal' the tests? At the end of the day your project depends on your subclass working. If you have a complete test suite for that subclass - specifically all the functionality you use - (as a specific part of your project) then you will immediately become aware of any issues (regardless of whether they relate to the superclass implementation OR your subclassing of it). And realistically you NEED to be aware of this, regardless of where the fault may lay.

You are subclassing to save time/money on coding. I do not think this relieves you of the burden to thoroughly unit test your subclass which means testing all the functionality you are using - if you can steal tests from the superclass fine - but I suggest independent testing would be the more prudent approach. Sure standards change, but so do module authors. It is not unknown for dud distributions to make it onto CPAN. I would rather fix broken tests I duplicated from a superclass than have broken production code. Lesser of two evils to me.