=head1 TITLE

Testing Parrot

=head1 A basic guide to writing tests for Parrot

This is quick and dirty pointer to how tests for Parrot should be
written.  The testing system is liable to change in the future, but
tests written following the guidelines below should be easy to port
into a new test suite.

=head2 How to write a test

First, find an appropriate file in F<t/op/*.t> (for basic ops) or
F<t/pmc/*.t> (for anything to do with PMCs). If there isn't an
appropriate file, create one.

Near the top of each file, you'll see a line like:

  use Parrot::Test tests => 8;

This sets up the test harness used to assemble and run the tests,
and lets it know how many tests you plan to run. New tests should be
added by:

 1. Incrementing the number of planned tests.

 2. Putting some code in like this:

	output_is(<<'CODE', <<'OUTPUT', "name for test");
		*** a big chunk of assembler, eg:
		print   1
		print   "\n" # you can even comment it if it's obscure
		end          # don't forget this...!
	CODE
	 *** what you expect the output of the chunk to be, eg.
	1
	OUTPUT

=head2 Ideal tests:

=over 4

=item o

Probe the boundaries (including edge cases, errors thrown etc.) of
whatever code they're testing.  These should include potentially
out of band input unless we decide that compilers should check for this
themselves.

=item o

Are small and self contained, so that if the tested feature breaks we
can identify where and why quickly.

=item o

Are valid. Essentially, they should conform to the additional documentation
that accompanies the feature (if any). [If there isn't any documentation, 
then feel free to add some and/or complain to the mailing list].  

=item o

Are a chunk of assembler and a chunk of expected output.

=back
