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