Before you decide where your going to put your tests, what in this sample are you going to test?

• main()

  Can perl invoke a function and assign the values it returns to an array?

  Can it then pass a reference to that array to another function?

  Someone will say that you should test what happens if the first function returns no files. There are two ways to handle that.

  • If there are no files, there is nothing to do and the second function can simply do nothing if there is nothing to do.

    sub extract_file {
        my( $file_ref ) = @_;
        while( @$file_ref ) {
            my $file = shift @$fileref;
            ## Do stuff
        }
        return;
    }
    [download]

    Note: while not for because the latter will expand the array to a list within the sub, and you've pretty much negated any reason for passing a reference.

  • Alternatively, main could report the absence of files

    my @files = get_xml_files() or die "No XML files to process";
    [download]

    Do we need to test that?

    We might run a quick check using the debugger or a repl to ensure that the precedence works. But do we need to re-run that test every time? Is it likely to change?

• get_xml_files()

  We could critique this in the basis that it returns a list instead of an array reference.

  We could critique it on the basis that substituting a user defined sub for a single call to a built-in is unnecessary.

  But is there anything to test here?

• extract_file()

  Assigning a ref to an array of files, to a scalar called $file could be mildly confusing, but until we see how it is used, it's just nit-picking.

  Beyond that, the sub is empty. Can we really apply any tests until we can know what it is going to do?

I appreciate that the snippet is intended to promote replies about how to go about testing a stand alone script, not how to test this particular example. But in the absence of any real code, it is pretty much impossible to suggest good ways of testing.

Hi BrowserUk,

Thanks for the comment...
As you have mentioned, my aim is to promote a reply on how to test a stand alone script , i.e. not to test the example I provide in my post.

And what I intend to do is to get used to write the test first before the actuals coding, as what is suggested by PBP chapter 18.1:


    So write the tests first. Write them as soon as you know what your interface will be.
    Write them before you start coding your application or module.


The impression I get from your comment


    But in the absence of any real code, it is pretty much impossible to suggest good ways of testing.

is that you need to code first, so you know what to test later.

The example I provide in my post is supposed to be the interface I'll use...


Thanks.

My point was that in the code you've posted, there is nothing to test, so it's hard to demonstrate any mechanism for testing it.

The example I provide in my post is supposed to be the interface I'll use...

Interface to what? So far, the code does nothing, and you've provided no indication of what it should do. To write tests first, you have to have to know what the end point (or an intermediate point) is going to be, so that you can construct a test to verify that when yu write the code, you have achieved it.

For example, you've indicated that you'll be processing XML files some how. But how?

• Will you be generating structure?

  If so, you might verify that structure.

  Maybe, by feeding in a known XML and hard coding a structural equivalent to verify against.

• Will you be transforming the input to some output? A different XML? CSV?

  If so, you might test by feeding in a known XML and comparing the result against a hand-coded output.

You (we) gotta know what you are aiming for before you can construct a test that will check your code, when you write it, achieves that.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Then you can load the script from another file, for example from a test file, without executing any code. That way you get simple access to all other subs.

(Disclaimer: I haven't actually tried it, but somebody recommended it in a recent thread).

It is good practice to divide your application internally into modules, even if you have no intention to publish those independently or even reuse them internally. This way, you would end up with a bunch of modules that you could test, and that should give you good coverage for most of your code. The remaining code will ideally be a simple script that just ties these modules together to form the application. That script should be either too trivial to warrant testing, or complex enough to be refactored into using some more modules.