Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Do you know where your variables are?
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??

I have yet to be convinced about the use of Test::More and it's brethren.

I've seen signs of people using these modules within the code being tested. That means that it either has to be removed for "production purposes" or disabled. If it is removed, then you risk its removal changing the nature of the code. If it is disabled, then it means that the production version carries the weight of the testcode. Neither is satisfactory IMO.

Using it the way you showed above, seperate from the real code, just used to simplify the validation of results makes some sense, but I'm still not sure.

My other basic qualm is that it tends to render the testcases to a series of individually descrete steps. Essentially unit tests of a very fine grain. I prefer my testcases to be more realistic, by which I mean, I like them to be as close as is practical to a real world usage of the code under test. This tends to do somewhat more than just exercising the API under test, in that it also tends to highlight design issues. If the API has been design such that it is awkward to use, this tends to become obvious. We've all encountered APIs that may look great on paper, from the designers perspective, but that force the coder to jump through hoops in order to use them in the real world. (Anyone used Java?:).

Coding the testcase as a realistic 'caller application' has the benefits of:

  • Highlighting design flaws or impracticalities.
  • Serves as a working--and maintained--programmers documentation example. So much better than the glorified 'prototype' examples that usually exist and often fall out of maintainance as soon as the documentation goes to press.

I can see the benefit of using the Test::* group to provide easy notification of where & why the overall testcase fails, but I still have qualms about their more abstract effects upon the testcases.

  • How do they effect timing issues?
  • How do they intereact with threading?
  • Can I easily disable the test verification code whilst leaving the testcase code they exercise in place?
  • Or do I have to code the tested code twice so that the exercised code will still be exercised (and its results and sideeffects still be available to the next part of the overal testcase)?
  • Can I easily reuse the testcase (with its embedded but disabled Test::* code) for profiling and benchmarking purposes?

From my breif exploratory visits to the Test::* group of modules, none that I have seen, yet satisfy these criteria.

I still don't have a satisfactory way of ensuring that my module-embedded testcases are not loaded into memory when the module is used. I have a very hooky method, but it has many flaws. If anyone has any suggestions on how to do this I'd love to hear them.


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.


In reply to Re: Re: My number 1 tip for developers. by BrowserUk
in thread My number 1 tip for developers. by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others about the Monastery: (8)
    As of 2014-04-16 06:01 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      April first is:







      Results (414 votes), past polls