#600: bytecode testing framework
---------------------+------------------------------------------------------
Reporter: allison | Owner:
Type: roadmap | Status: new
Priority: normal | Milestone: 1.7
Component: none | Version:
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
---------------------+------------------------------------------------------
Comment(by Util):
In #parrotsketch,
http://irclog.perlgeek.de/parrotsketch/2009-09-22#i_1527763 , Allison
asked me to put together a first draft of what I think might need to be
done.
I see two distinct needs that shape the issue:
1) Now that Packfile PMCs work, some tests, written in PIR, will need to
create or manipulate a separate piece of bytecode, and need to run the
resulting .pbc using the same parrot.exe that is running the test PIR. The
.pbc never has no true equivalent .pir source on disk.
For example, examples/pir/make_hello_pbc.pir creates its own
`generated_hello.pbc`, then exercises it by `load_bytecode
'generated_hello.pbc'`. How should this be converted into a t/.t test?
What services should the test framework provide to support this kind of
testing, to reduce redundant code?
Is it healthy to run that last step via `load_bytecode`, or should a
separate invocation of `./parrot generated_hello.pbc` be used?
One landmine to avoid is (just) compiling make_hello_pbc.pir to .pbc; that
is, conflating this with part (2), below.
2) Because IMCC can load-and-run .pir without writing bytecode to a file,
a (possible?) gap exists between the codepaths of running `./parrot
FOO.pir` vs `./parrot -o FOO.pbc FOO.pir && ./parrot FOO.pbc`. It is
possible for the output of these two cases to disagree, although this
would always indicate a bug.
We need to be able to run any .pir test in either codepath (direct .pir,
or .pir->.pbc-then-run).
How to approach? What API?
* Extend current testing framework to have a flag that means "invisibly
compile this PIR to .pbc, and run the .pbc instead of the .pir"?
* ENV var to force everything that would have been run as .pir to be run
as .pbc?
* ENV var to force everything that would have been run as .pir to be run
and tested *twice*, once as .pir and once as .pbc?
* Magic setting in `use Test::More` line?
* Make a new dimension in the `make` testing targets? (`make testc` vs
`make testc-pbc`)
.t needs to do the right thing.
Actual coding seems straightforward, except for the hierarchal aspect of
exceptions, which might not be captureable.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/600#comment:2>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
