Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Inheriting Tests and Other Test Design Issues

by tilly (Archbishop)
on Sep 27, 2003 at 20:47 UTC ( #294678=note: print w/replies, xml ) Need Help??


in reply to Inheriting Tests and Other Test Design Issues

..but even bad tests are better than no tests, right?

Wrong.

A bad API is not improved by a set of tests that nail down every aspect of its misbehaviour. Furthermore tests are code like any other, and good coding principles apply just as much.

About your main question, I agree that inheriting the tests is better, and here is the argument that I would give back to the other programmer. Suppose that your subclass is written and you copy tests. If anyone now extends the superclass, then either subclasses have untested behaviour or else the implementer has to track down every subclass and cut-and-paste the behaviour. This is exactly the kind of cut-and-paste which is likely to break that object-oriented techniques are supposed to protect you from.

However if your strategy is to inherit tests then both your present and future behaviour will get tested. True, it is possible to break your module by changing just the core module and changing its tests without notifying you. But this breakage is exactly the same risk that anyone using any module faces. No strategy can really protect you from rogue modifications, and attempting to do so by producing masses of redundant code loses productivity to what is really an education issue.

  • Comment on Re: Inheriting Tests and Other Test Design Issues

Replies are listed 'Best First'.
Re: Re: Inheriting Tests and Other Test Design Issues
by tachyon (Chancellor) on Sep 28, 2003 at 01:10 UTC

    If anyone now extends the superclass, then either subclasses have untested behaviour or else the implementer has to track down every subclass and cut-and-paste the behaviour.

    No, the complete behaviour of the superclass is to an extent immaterial to a widget that uses a subclass of it. As far as the widget's functionality is concerned what needs to happen is for the subclasser to test what is actually in use. That way MY tests fail if MY code is going to fail - this is ultimately what is required of tests. They let you know that some change somewhere has caused some new behaviour. The fact that a test exists means that that behaviour was probably important enough for you to write a test for in the first place and thus you should be concerned.

    masses of redundant code loses productivity

    A thorough test of subclass behaviour is not, and never will be, redundant. It simply ensures that the subclass continues to behave the way YOU expected when YOU wrote the code that uses it. If that changes (for whatever reason) you probably do have an issue you need to look at.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://294678]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2020-04-06 02:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The most amusing oxymoron is:
















    Results (36 votes). Check out past polls.

    Notices?