Your skill will accomplish what the force of many cannot |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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
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. cheers tachyon s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print In reply to Re: Inheriting Tests and Other Test Design Issues
by tachyon
|
|