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.