Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
I find that I do this more and more. I also would underscore what Kyle had to say about writing the perldoc first, or at least the synopsis. Then I try to document each public method as I write those as well.

In fact, I have code which is being used in production, just a couple of weeks into development, and the scripts which are actually being run are in my t/ directory. I've run a module in development for weeks at a time like this, from the t/ directory, doing production work, as I continue to develop the module, adding features, monitoring output, refactoring early efforts, tightening up pieces I have to handle manually until its ready for prime time.

I find it very useful and helpful to watch a test fail, and then to resolve each error in turn as it presents itself, until the test passes.

I code in vim, using konsole on a gui desktop to access a command line. Konsole permits multiple tabs, each in its own directory, with its own tab label, perhaps even connected to its own server. I'll use three adjancent tabs all in my sandbox/My-New-Project/ folder. One I use to vim lib/My/New/Project.pm. The next tab invokes vim t/20-my-new-project.t. The third is used to invoke `time perl t/20-my-new-project.t`.

If a database is involved, a fourth tab will give me a psql or mysql prompt to the affected database, even when my test scripts are directly monitoring the results in the database, as well. If I'm writing a cgi script, I'm likely to also have a browser opened to localhost/t/testscript-my-new-project.cgi, as well.

I don't write tests first, so much as along with. Usually just a test or three at a time, then the code it tests, then a couple more tests, and some additional code. By the time I've built a ->new() method there may be a dozen, or two or more tests making sure that all the sanity checks are working.

I've found that I spend far less time debugging this way than I use to. No more chasing errors around. When I have three or five tests which reasonably exercise an internal method, changes are less scary.

I also use Devel::Cover, is it, to examine the coverage offered by my test suite. When I get stuck or bored moving forward in implementing a design, I might spend some time looking at how I can improve coverage of my test suite.

My first supposedly Test-Driven-Development project got me working code, and a well populated t/ directory. But I was aghast at how few branches were actually exercised by my tests when months later I applied Devel::Cover to it. Now I run my test suite under Devel::Cover from time to time as I go and fill in the holes. It leaves me far more confident in the results I produce.

And as one client mentioned to me, it left her far more confident in my work as well. I sent her the test results. The well named tests (after bugs or variations in the data) left her confident not only that the module I built for her would appropriately process her test data she had sent me, but would also handle the 5,000 records that module was written to process, as well.

-- Hugh

if( $lal && $lol ) { $life++; }

In reply to Re: Does anybody write tests first? by hesco
in thread Does anybody write tests first? by amarquis

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!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • 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
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            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 chanting in the Monastery: (3)
    As of 2019-10-21 04:55 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      Notices?