Re: Literal Values

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