Skip to content
This repository has been archived by the owner on Sep 15, 2023. It is now read-only.

Comment/assert events are emitted in the wrong order if interleaved #18

Closed
anko opened this issue May 4, 2015 · 2 comments · Fixed by #21
Closed

Comment/assert events are emitted in the wrong order if interleaved #18

anko opened this issue May 4, 2015 · 2 comments · Fixed by #21

Comments

@anko
Copy link

anko commented May 4, 2015

Testcase:

cat test.tap:

TAP version 13
# c1
ok
# c2
ok
1..2

./bin/cmd.js < test.tap | grep -v line (grep removes line events):

  [ 'version', '13' ],
  [ 'comment', '# c1\n' ],
  [ 'comment', '# c2\n' ],
  [ 'assert', { ok: true, id: 1 } ],
  [ 'assert', { ok: true, id: 2 } ],
  [ 'plan', { start: 1, end: 2 } ],
  [ 'complete',
    { ok: true, count: 2, pass: 2, plan: { start: 1, end: 2 } } ] ]

I expected this to parse as version comment assert comment assert plan complete.

This happens with any number of comment-test pairs, but only if comments and tests are interleaved as single copies. This also happens when using this module via require.


The line events happen in the correct order.

./bin/cmd.js < test.tap | grep line:

[ [ 'line', 'TAP version 13\n' ],
  [ 'line', '# c1\n' ],
  [ 'line', 'ok\n' ],
  [ 'line', '# c2\n' ],
  [ 'line', 'ok\n' ],
  [ 'line', '1..2\n' ],
@simov
Copy link

simov commented May 30, 2015

Same here - gist to reproduce it tape@4.0.0 + tap-parser@1.1.4

I'm using substack's tape as tap producer instead of tap as a lot of tap reporters for tape are using tap-parser internally. No luck for me however.

node test.js

TAP version 13
# test 1-1
ok 1 1-1-1
ok 2 1-2-2
# test 1-2
ok 3 1-2-1
ok 4 1-2-2

1..4
# tests 4
# pass  4

# ok
node test.js | node parser.js

version 13
comment # test 1-1

assert { ok: true, id: 1, name: '1-1-1' }
comment # test 1-2

assert { ok: true, id: 2, name: '1-2-2' }
assert { ok: true, id: 3, name: '1-2-1' }
assert { ok: true, id: 4, name: '1-2-2' }
plan { start: 1, end: 4 }
comment # tests 4

comment # pass  4

comment # ok

complete { ok: true, count: 4, pass: 4, plan: { start: 1, end: 4 } }

@isaacs
Copy link
Member

isaacs commented May 30, 2015

See the explanation and options here: #19 (comment)

isaacs added a commit that referenced this issue May 31, 2015
Keep a queue of comments that occur when we're waiting on potential
diags for a previous assert.

Then emit those comment events all at once when we are sure that either
the test point line is finished (without diags) or that the diags are
done.

Fix #18
Fix #19
Fix #20
@isaacs isaacs closed this as completed in #21 Jun 1, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants