Re: RFC:: Test::Example
Gabor Szabo wrote:
Going along the path of testing the examples in my distribution,
I think it could be generalized. What do you think about this?
I think putting the expected output into files fractures the test so that its
not obvious from just looking at the test what's going on. You have to jump
around.
It also might be handy to unify the input/output format so its more like a
conversation. Compare splitting things up:
stdout = 'END',
Please enter an email address:
Please enter an email address:
Mailing spam now...
END
stdin = 'END',
schwern
[EMAIL PROTECTED]
END
stderr = 'END',
schwern is not a valid email address
END
With unifying them:
conversation = 'END'
OUT: Please enter an email address:
IN : schwern
ERR: schwern is not a valid email address
OUT: Please enter an email address:
IN : [EMAIL PROTECTED]
OUT: Mailing spam now...
END
Which would you rather write and maintain?
Also, I'm not sure test_all_examples() is all that useful as it allows you to
test each example only once. Presumably you're going to want to try a few
different inputs.
Finally, what does this module have to really do with examples? It just runs
programs. Is there already a module to test running scripts? If not, perhaps
this can be it but don't call it Test::Example, call it Test::Script.
chdir 'myexamples';
system($h{script} @{ $h{argv} } $h{stdin} temp_out 2 temp_err);
Very, very, very un-cross platform. Don't even describe it this way in the
docs, non-Unix gurus will have no idea what you're talking about.
Instead tie/reopen STDOUT, STDIN and STDERR.
Re: RFC:: Test::Example
I think you've made an invalid assumption that examples will just happen
to have a console or input/output interface.
How do I show an example of using Wx.pm by implementing Windows Notepad
in the example. Or a POE asyncronous application, or a curses interface,
and so on.
Adam K
Gabor Szabo wrote:
Going along the path of testing the examples in my distribution,
I think it could be generalized. What do you think about this?
Gabor
=head1 NAME
Test::Example - Check if all the examples in the distribution work
correctly
=head1 SYNOPSIS
use Test::Example;
test_all_examples();
or
use Test::Example;
foreach my $file (glob 'myexamples/*.plx') {
test_example(
dir= 'myexamples',
script = $file,
stdout = stdout/$file,
stderr = stderr/$file,
);
}
=head1 METHODS
=head2 test_all_examples
Goes over all the .pl files in the eg/ examples/ /sample/ (...?)
directories runs each one of the scripts using Ltest_example.
Options given to test_example are:
test_example(
dir= 'eg', # the name of the relevant
directory
script = 'scriptname.pl', # the name of the current .pl file
stdin = 'scriptname.pl_stdin',
stdout = 'scriptname.pl_stdout',
stderr = 'scriptname.pl_stderr',
);
=head2 test_all_examples_do
The same as test_all_examples but
=head2 test_example
test_example(
dir = 'myexamples',
script = 'doit.pl',
stdin = 'file_providing_stdin',
stdout = 'file_listing_expected_output_of_doit',
stderr = 'file_listing_expected_errors_of_doit',
argv= ['command', 'line', 'arguments'],
);
Before running doit.pl chdirs into the 'myexamples' directory.
doit.pl is executed using system. The list of values provided
as argv are supplied as command line parameters.
Its STDIN is redirected from the file that is given as 'stdin'.
Its STDOUT and STDERR are captured.
In short, something like this:
chdir 'myexamples';
system($h{script} @{ $h{argv} } $h{stdin} temp_out 2 temp_err);
Once the script finished the content of temp_out is compared to
the expeced output and the content of temp_err to the expected errors.
If no 'stderr' key provided then the expectation is that nothing
will be printed to STDERR.
=head2 test_example_do
The same as L/test_example but instead of using Csystem to run the
external
script it will use Cdo 'scriptname.pl'
=cut
RFC:: Test::Example
Going along the path of testing the examples in my distribution,
I think it could be generalized. What do you think about this?
Gabor
=head1 NAME
Test::Example - Check if all the examples in the distribution work correctly
=head1 SYNOPSIS
use Test::Example;
test_all_examples();
or
use Test::Example;
foreach my $file (glob 'myexamples/*.plx') {
test_example(
dir= 'myexamples',
script = $file,
stdout = stdout/$file,
stderr = stderr/$file,
);
}
=head1 METHODS
=head2 test_all_examples
Goes over all the .pl files in the eg/ examples/ /sample/ (...?)
directories runs each one of the scripts using Ltest_example.
Options given to test_example are:
test_example(
dir= 'eg', # the name of the relevant directory
script = 'scriptname.pl', # the name of the current .pl file
stdin = 'scriptname.pl_stdin',
stdout = 'scriptname.pl_stdout',
stderr = 'scriptname.pl_stderr',
);
=head2 test_all_examples_do
The same as test_all_examples but
=head2 test_example
test_example(
dir = 'myexamples',
script = 'doit.pl',
stdin = 'file_providing_stdin',
stdout = 'file_listing_expected_output_of_doit',
stderr = 'file_listing_expected_errors_of_doit',
argv= ['command', 'line', 'arguments'],
);
Before running doit.pl chdirs into the 'myexamples' directory.
doit.pl is executed using system. The list of values provided
as argv are supplied as command line parameters.
Its STDIN is redirected from the file that is given as 'stdin'.
Its STDOUT and STDERR are captured.
In short, something like this:
chdir 'myexamples';
system($h{script} @{ $h{argv} } $h{stdin} temp_out 2 temp_err);
Once the script finished the content of temp_out is compared to
the expeced output and the content of temp_err to the expected errors.
If no 'stderr' key provided then the expectation is that nothing
will be printed to STDERR.
=head2 test_example_do
The same as L/test_example but instead of using Csystem to run the external
script it will use Cdo 'scriptname.pl'
=cut
