On Tue, 12 Nov 2002 17:00:17 +0000, Dave Whipp wrote:
(cross-posting to perl.qa for other perspectives)
> When I look at this, I find myself wanting to separate the control from the
> data. Here's an alternative:
>
> my @input = qw( 4.5 0.0 13.12343 );
> my @output = qw( 4.5 0.0 13.12343 ); # can't assume that input==output
>
> my $code = join(";", map {"print $_"} @input);
> my $expect = join( "", @output);
> output_is($code, $expect, "Simple Floats");
>
> This is, perhaps, slightly harder to grok initially. But its easier to
> extend the test data; and also to make control-path changes (such as added
> the \n to the print statement). It might be better to use a hash for the
> test data.
Yes, that is easier to extend. I'm not a big fan of mushing together several
different tests into one output_is() chunk, but that's because we don't have
anything of finer grain yet.
It'd be nice to write something like:
output_lines(<<INPUT, <<OUTPUT, <<NAMES);
4
0.0
13.12343
INPUT
4
0.0
13.12343
OUTPUT
int
float
longer float
NAMES
and get individual tests as:
ok 1 # int
ok 2 # float
ok 3 # longer float
Maybe that's a wrapper around output_is() for the string test. Maybe it should
be a new method in the Parrot test module.
> It is possible to make this type of test much easier to read. A mechanism I
> have used in the past is to put the test data into a table (I used html).
> Then, you have the test data and expected output as a nice table in a
> document; and a simple piece of code to extract tests from it (assuming you
> use a perl5 module to parse the table).
Being able to specify an output separator (assuming "\n" in its absence) may
alleviate this.
-- c
