Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Testing inherited classes

by citromatik (Curate)
on Nov 09, 2010 at 13:42 UTC ( #870301=perlquestion: print w/replies, xml ) Need Help??
citromatik has asked for the wisdom of the Perl Monks concerning the following question:

Hi all

Recently, one of my CPAN modules have been criticized for not having enough tests. This module is a class that only serves methods to other classes by inheritance and lacks a constructor.

The problem is that different independent modules can inherit this one:

Base # No constructor Base::X # Inherits Base, has constructor Base::Y # Inherits Base, has constructor

What is the best way to test Base without assuming that Base::X or Base::Y are installed? (In fact, they can not be installed before Base, because package Base is a pre-requisite of Base::X and Base::Y). Currently I test Base as part of the Base::X and Base::Y testing

Thanks in advance


Replies are listed 'Best First'.
Re: Testing inherited classes
by chromatic (Archbishop) on Nov 09, 2010 at 16:51 UTC

    If this class exists so that other classes can inherit from it, write a class which inherits from it and test that the subclass behaves as you would expect it to behave if it inherited properly from this class.

Re: Testing inherited classes
by choroba (Chancellor) on Nov 09, 2010 at 14:52 UTC
    Wouldn't it be better for Base to have a constructor that would die with "Cannot instantiate an abstract class"?
    Update: You can also create Base::Test in your test script. Thus you can test what Base is really designed to do - to provide abstract parent.
Re: Testing inherited classes
by sundialsvc4 (Abbot) on Nov 09, 2010 at 16:07 UTC

    Or, since constructors can have any name, what if you defined sub testing_constructor?   This method would only be invoked by the module-testing code.

    To my way of thinking, the tests of the base-class (having thus been made possible by this alternate, special-purpose constructor) would of course be limited to functionality that was strictly in the base ... and that could, meaningfully, be “tested” in such abstract isolation.   (Resist the temptation to have “tests to have tests.”   Tests must actually make sense.)

    You might consider coding the abstract base-class so that it had such things as ... a new method that blew up, and stub-methods that also blew up.   Just so that the abstract class wouldn’t do anything harmful if accidentally invoked in a senior moment brief episode of amnesia...

Re: Testing inherited classes
by kcott (Chancellor) on Nov 10, 2010 at 07:08 UTC

    With your current setup, you are maintaining the same tests in multiple subclasses. If you add a Base::NewSubclass in the future, you're going to have to repeat all of your Base tests in that module too and add to the list of modules that need to be maintained in parallel. Anyone adding their own Base::CustomSubclass is also going to face the same issues.

    You've already received good general advice above. If you identify the Base class in question, you may receive better specific advice.

    -- Ken

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://870301]
Approved by ELISHEVA
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (11)
As of 2017-08-22 21:03 GMT
Find Nodes?
    Voting Booth?
    Who is your favorite scientist and why?

    Results (341 votes). Check out past polls.