scottcorgan / tap-out

A different tap parser
MIT License
23 stars 28 forks source link

error handling with Uint8Array #9

Closed mattdesl closed 9 years ago

mattdesl commented 9 years ago

(sorry for all the issues :smile:)

I've noticed that assert.error is giving unusual results when tape emits the expected/output on its own line, like this:

not ok 10 should be equivalent
  ---
    operator: deepEqual
    expected:
      { 0: 0, 1: 0, 10: 0, 11: 255, 12: 0, 13: 0, 14: 0, 15: 255, 2: 0, 3: 221, 4: 0, 5: 0, 6: 0, 7: 255, 8: 0, 9: 0 }
    actual:
      { 0: 0, 1: 0, 10: 0, 11: 255, 12: 0, 13: 0, 14: 0, 15: 255, 2: 0, 3: 255, 4: 0, 5: 0, 6: 0, 7: 255, 8: 0, 9: 0 }
    at: Test.assert (http://localhost:52238/script.js:5421:17)
  ...
ok 11 should be equivalent
not ok 12 should be equivalent
  ---

Can reproduce with t.deepEqual(new Uint8Array(10), new Uint8Array(5))

This is also affecting the latest version of tap-spec on GitHub. Notice the actual: field is empty here:

screen shot 2015-06-03 at 1 22 01 pm

One thing that would fix this (with minimal changes to tap-spec) is to have error.raw just be a string. Then tap-spec could split newlines, trim, and re-pad it as desired. I can PR if needed. This doesn't fix the assert.error.expected fields though.

mattdesl commented 9 years ago

sent a PR in case you are interested #10

scottcorgan commented 9 years ago

Appreciate, I'll take a look later today.

scottcorgan commented 9 years ago

Merged