in reply to Re^4: Testing A Stand Alone Application
in thread Testing A Stand Alone Application

Then, off the top of my head there are perhaps four things to test.

  1. Does it do the right thing when no .xml files are found?
  2. Does it do the right thing if a .xml file is found that fails to parse as XML?
  3. Does it do the right thing if the file contains XML, but none of the tags you are looking for?
  4. Does it do the right thing--produce the appropriate output in the appropriate form--when the file is found, contains XML and the required tags?

A test script (not using Test::*) might look something like: 

#! perl -slw
use strict;
use constant DIR => '/path/to/dir/';

## temporarially rename the test files 
rename $_, $_ . 'X' for glob DIR . '*.xml';

## And compare the output with a reference file 
## containing the expected output for the no xml case.
system 'perl.exe thescript.pl > noxml.out && diff noxml.out noxml.ref'
+;

## Get the xml files back again.
for my $file ( glob DIR . '*.xmlX' ) {
    my $new = $file;
    chop $new;
    rename $file, $new;
} 

## And test the other three cases by diffing the actual output
## produced by processing 3 test files constructed to demonstrate them
## Against a file containing the expected output.
system 'perl.exe thescript.pl > xml.out && diff xml.out xmp.ref';

[download]

Initially, you'll be verifying your output manually. But then you redirect the validated output to a file and it becomes the reference for future tests. Use Carp to give you feedback on where things went wrong.

If you add temporary/conditional tracing to track down problems, they do not prevent the test from verifying those bits that worked.

Run the test script from within a programmable editor and you can use the traceback provided by Perl to take you straight to the site of failing code.

As you think of new criteria to test, you construct a new, small .xml file to exercise each criteria, and the second run (system) above will run them automatically. So, your tests consist of a 10 line script you reuse, and a short .xml file for each criteria.

Or you could do it the hard way.

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

Replies are listed 'Best First'.
Re^6: Testing A Stand Alone Application
by est (Acolyte) on Mar 13, 2008 at 05:06 UTC
    Hi BrowserUk,

    Now, that gives me an idea on how to test :)
    Thanks for that!

    Anyhow, your suggestion seem to test the entire application, i.e. a black box testing, where we pass an input to the application and diff the output. But I can't test the output from each subroutine...

    Am I right in thinking that the only way to test each individual sub would be to create a module eventhough if the code is not re-usable by any other scripts (as suggested by Thilosophy)?

    Thanks!

[reply]
      Am I right in thinking that the only way to test each individual sub would be to create a module eventhough if the code is not re-usable by any other scripts (as suggested by Thilosophy)?

      All you have to do to test individual subs is to load a pile of code somehow and control the flow of execution from something other than the program itself.

      Granted, this is easier if you create one or more modules, but it's not a requirement. (The purpose of modules is to help you organize code, not just to reuse it.)

[reply]
      Am I right in thinking that the only way to test each individual sub would be to create a module eventhough if the code is not re-usable by any other scripts

      No. There are as many other ways to test as your imagination can dream up.

      You could for example, use a command line switch that when supplied causes a different main-like sub to be invoked in place of main. 

      ...
if( $DEBUG ) {
    debug_main()
}
else{
    main();
}

## The rest of the code

      [download]

      And run the tests using perl -s TheScript.pl -DEBUG

      Or using Smart::Comments something like: 

      ...
### debug_main()
### exit;
main()
# the rest of the code
...

      [download]

      Now you run your tests using perl -MSmart::Comments TheScript.pl

      And within debug_main() you can use any testing tools that you want. You could, for example, use the traditional ok(..) and not_ok( ... ), and then use the test harnesss or prove commands with an appropriate command line switch to perform white box testing.

      You could even combine the two. Rather than having to structure your application to suit the test tools, you can structure your application in whatever way best suites its requirements, and use whichever combination of test methodologies best suit your needs.

      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.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom