Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: Re: Tests (Safety) vs Contracts (Correctness)

by blssu (Pilgrim)
on Sep 30, 2003 at 13:58 UTC ( #295289=note: print w/replies, xml ) Need Help??

in reply to Re: Tests (Safety) vs Contracts (Correctness)
in thread Inheriting Tests and Other Test Design Issues

I wonder if placing tests outside the main code base is the best approach. Perl encourages this with the default MakeMaker machinery, but whenever I really *need* a test result, a built-in test I can call from the debugger (or insert into production code as a guard) would be better. Most of my tests sprout in the main code and then are transplanted into a test suite. Why do this extra work to make the tests less useful?

This is what I was thinking when I wrote about inheriting tests. I meant a subclass should inherit tests, not that the external subclass test suite should inherit tests. It would be useful to run superclass tests on instances of the subclass in a "real world" environment.

Sorry for the confusion. I should have known better as I read the whole thread, including dws' clarification, before replying. You've packed a lot of material into your reply, so I'll try to keep the same organization as you.

  1. Duplication.

    I don't understand your optimisim for achieving nothing by running the superclass tests on subclasses. It would at least catch bless $copy, 'Fubar' errors in the copy constructor... ;)

    Different subclasses can violate the invariants of the parent in different ways. This is similar to smoke testing of perl on different architectures. The majority of smoke testing runs the same code with the same results. It's the differences that are important, but we don't know the differences until after the tests are run.

  2. Targeting.

    I shouldn't have been so flip. Most software testing is bean counting as you call it. Measuring 100% code coverage in a unit test is the purest form of bean counting. Running a regression test to verify a change is bean counting too. Neither of these are really "testing" anything other than the system's internal consistency. Isn't that exactly what accounting checks?

    Your whitebox vs blackbox testing strike me as different schools of accounting, not as having different purposes. This testing seems to be a substitute for formal methods. (Whether formal methods will ever work for software is an entirely different question.)

    Examples of testing with different purpose are security, performance and usability.

  3. Binding.

    It's not clear to me why loosely coupled classes would have tightly coupled test suites, but I don't doubt it happened. I am surprised to hear you don't think external factors often influence implementation. Rejecting new code due to its' test suite is more rational than rejecting it due to its' politics -- it wish it were more common too...

    Close coupling is a problem. Test suites that are artificially forced to be loosely coupled in an otherwise closely coupled system may be worse.

You undoubtedly have accumulated wisdom -- probably more than me. I think I've mostly just accumulated disgust with the status quo.

Yep, the tyres thing. If the analogy was primarily connected with a hierarchy of tests and interacting systems, I'd have no trouble with it. Unfortunately it's easy to look at that analogy and jump to an incorrect understanding. Safety testing and specification testing are not points on the same continuum.

"This steak is like a turd." That could mean the steak has a lovely chocolate brown color -- but the reader most likely would not come to that conclusion.

Replies are listed 'Best First'.
Help! I think I'm leaking..
by BrowserUk (Pope) on Sep 30, 2003 at 14:08 UTC
    "This steak is like a turd." That could mean the steak has a lovely chocolate brown color -- but the reader most likely would not come to that conclusion.

    ...I keep wiping the tears from my eyes, but they just keep coming:)

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (1)
As of 2021-09-24 00:31 GMT
Find Nodes?
    Voting Booth?

    No recent polls found