Re: Testing A Stand Alone Application

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.

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."

Comment on Re: Testing A Stand Alone Application Select or Download Code

Replies are listed 'Best First'.
Re^2: Testing A Stand Alone Application by est (Acolyte) on Mar 13, 2008 at 00:06 UTC
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.	[reply]
Re^3: Testing A Stand Alone Application by BrowserUk (Patriarch) on Mar 13, 2008 at 00:31 UTC
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."	[reply]
Re^4: Testing A Stand Alone Application by est (Acolyte) on Mar 13, 2008 at 00:53 UTC
Ahhh fairynuff, I should have provided more information about the interfaces... okay, there you go: get_xml_files input: a (exist) directory objective: glob all xml files in the directory output: a list of filename.xml or empty list extract_file input: a list of xml files objective: parse the xml file (using XML::Simple) find a specific tag, e.g. IMPRESSIONS output: write to STDOUT the filename.xml and the IMPRESSIONS found I think that should answer your question about the interface? I know that functionality can be done in one line by grep IMPRESSIONS .xml* But again it's only an example...	[reply]
Re^5: Testing A Stand Alone Application by BrowserUk (Patriarch) on Mar 13, 2008 at 01:49 UTC
Re^6: Testing A Stand Alone Application by est (Acolyte) on Mar 13, 2008 at 05:06 UTC
Some notes below your chosen depth have not been shown here