jerry gay wrote:
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes <[EMAIL PROTECTED]> wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:

1) I am not sure how to deal with pcc_sub's so I put them into
t/pmc/objects-pcc_sub.t
2) There appears to be a bug that shows up in complex.t ->
complex_divide_by_zero_*(). I have skip'ed those tests and will submit
a simplified bug report and test.

This drops the test run time for these from 24 seconds to less than 2.
Also, this patch should hopefully apply cleanly. I had to make some
changes to the $Id: line in the patch by hand.

-Mark

On Fri, Oct 17, 2008 at 10:35 AM, Mark Grimes <[EMAIL PROTECTED]> wrote:
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label.  If the exception is
raised, control will jump to that label.  t/pmc/resizablestringarray.t
uses this style.
Thanks Christoph. That is pretty straight forward. I'll update and
send a new patch.

when I was on my PIRifying binge, but I didn't have nearly enough
patience at the time.
Agreed. Takes quite a bit of patients, but I have put together a vim
function and perl script that takes care of some of the more common
test idioms automatically. I'll make it public after I clean it up a
bit more.

Any suggestion on how to deal the the .pcc_sub tests. I admit, I don't
quite understand what pcc_sub are, and I get an error whenever they
are included:

 error:imcc:syntax error, unexpected PCC_SUB, exprint $end ('.pcc_sub')

There are two tests in object.t that use them.

s/\.pcc_sub/\.sub/g; ##  this will fix it
~jerry



Hi Mark,

I've reviewed the updated complex.t and string.t, and have a few suggestions. The patch no longer applies cleanly to objects.t, and I thought it'd be better to let you merge the recent changes from svn and add the .pcc_sub tests, given Jerry's suggestion. I'll be glad to review and commit an updated version.

It's a good idea to test for exception types rather than exact messages. This keeps the tests passing if the wording of the message is changed. The exception type is much more likely to remain constant. This recommended but not a blocker.

Test messages for shouldn't be blank. If a test fails, it should be fairly obvious from the output what went wrong. This makes debugging easier, which is always a good goal.

In string.t, don't worry about preserving comments about failing tests if the relevant test passes.

Use $P0 instead of P0.  Both currently work, but the non-$ syntax is deprecated.

This is a minor nit, but "-ve" and "+ve" generally expand to "negative" and "positive". Changing "out_of_bounds_substr_neg_ve_offset" would increase readability, although it's already a mouthful.

Again, thanks for working on this.

Christoph

Reply via email to