Dave Whipp wrote:
Tanton Gibbs wrote:
We also might want some way of specifying a test that will cause an
error...for example
0b19 ERROR
I'm not exactly sure how to specify this, but it is often important to
document what is not allowed along with what is allowed.
I definitely agree that we need some error tests: I agree with your "ERROR" indicator as the trigger: but I need an example of what the output of the code-generator should look like. After that: yes, we should add a whole load of negative tests.
Well, Test::More has an C<isnt>, so C<Parrot::Test> should have an <output_isnt>. If not, it shouldn't be too hard to write one. I'll try to start on some error tests this weekend, at the latest.
I think that it'd also be nice to get some consensus on which format of test we should maintain: the table version, or the raw-code version.
I think the consensus when Chromatic brought the subject up was to use the testing system that Parrot uses; however, your table version is kinda nice.
Dave.
