Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by goon (3162) on 2004.03.25 6:22 (#29655) Homepage Journal


    • Hi Andy,

            I'll add a few (for what it's worth - after spending some time writing test code today) to the list (and a few q's)
    btw I'm coming from a python [python.org]
    testing pov so I'm curious how testing approachs differs for perl.

    *automate where possible
    -write automated test tools to generate test code stubs from source code
      to save time, effort and concentrate on thinking about tests.
    *make tests pass by default
    -lots of talk about failing code by default. the reverse is faster
      as reports are cleaner so it's easier to see if the current test your working on
      is ok.
    *test by intention
    -and then comment what the test is trying to acheive
    -try reading old test code after many months and try to understand *why* you wrote it.
    *ship test code
    -I see this with most perl code anyway but it's worth including.

    what I would be interested to know is do you?

    *write the tests before writing the code?
    -when do you write them?
    -for me it's... think about errors->code->auto-gen test->write testcode.
    *average number of tests you have per module?

    --
    bootload [netspace.net.au], groking softwa