=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),
F<t/pmc/*.t> (for anything to do with PMCs), and F<t/src/*.t> for C
source code tests. 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

or, if it is a C test, some code like this:

    c_output_is(<<'CODE', <<'OUTPUT', "name for test");
    #include <stdio.h>
    #include "parrot/parrot.h"
    #include "parrot/embed.h"
    
    int do_test(Interp *interpreter);
    
    int main(int argc, char* argv[]) {
        Interp* interpreter;
        interpreter = Parrot_new();

        if ( interpreter == NULL ) return 1;
        interpreter->lo_var_ptr = &interpreter;
    
        Parrot_init(interpreter);
        return do_test(interpreter);
    }
    
    int do_test(Interp *interpreter) {
        /* Your test goes here. */
        printf("done\n");
        return 0;
    }
    CODE
    # Anything that might be output prior to "done".
    done
    OUTPUT

Note, it's always a good idea to output "done" to confirm that the
compiled code executed completely.

=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
