You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$ node foo.js
[Mon Dec 05 2011 11:24:58 GMT-0800 (PST)] Start.
# one
ok 1 one potato
# two
not ok 2 Timeout!
---
file: timers.js
line: 83
column: 39
stack:
- getCaller (/Users/trentm/src/node-tap/lib/tap-assert.js:376:17)
- assert (/Users/trentm/src/node-tap/lib/tap-assert.js:17:16)
- Function.fail (/Users/trentm/src/node-tap/lib/tap-assert.js:91:10)
- Test._testAssert [as fail] (/Users/trentm/src/node-tap/lib/tap-test.js:86:16)
- Test.timeout (/Users/trentm/src/node-tap/lib/tap-test.js:30:8)
- Object._onTimeout (native)
- Timer.callback (timers.js:83:39)
...
# three
not ok 3 Timeout!
---
file: timers.js
line: 83
column: 39
stack:
- getCaller (/Users/trentm/src/node-tap/lib/tap-assert.js:376:17)
- assert (/Users/trentm/src/node-tap/lib/tap-assert.js:17:16)
- Function.fail (/Users/trentm/src/node-tap/lib/tap-assert.js:91:10)
- Test._testAssert [as fail] (/Users/trentm/src/node-tap/lib/tap-test.js:86:16)
- Test.timeout (/Users/trentm/src/node-tap/lib/tap-test.js:30:8)
- Object._onTimeout (native)
- Timer.callback (timers.js:83:39)
...
ok 4 three potato
not ok 5 end called more than once
---
file: /Users/trentm/src/node-tap/tmp/foo.js
line: 33
column: 5
stack:
- getCaller (/Users/trentm/src/node-tap/lib/tap-assert.js:376:17)
- assert (/Users/trentm/src/node-tap/lib/tap-assert.js:17:16)
- Function.fail (/Users/trentm/src/node-tap/lib/tap-assert.js:91:10)
- Test.end (/Users/trentm/src/node-tap/lib/tap-harness.js:102:29)
- Test.<anonymous> (/Users/trentm/src/node-tap/tmp/foo.js:33:5)
- Test.<anonymous> (native)
- Test.<anonymous> (events.js:61:17)
- Test.emit (/Users/trentm/src/node-tap/lib/tap-test.js:102:8)
- GlobalHarness.<anonymous> (/Users/trentm/src/node-tap/lib/tap-harness.js:86:13)
- Array.0 (native)
...
# four
ok 6 four
1..6
# tests 6
# pass 3
# fail 3
[Mon Dec 05 2011 11:25:05 GMT-0800 (PST)] Finished executing test two.
IOW, this does NOT work as expected.
On a possibly related note, you can see from the printed timestamps that the test run does not terminate until the 7s "setTimeout" still runs to completion. Say this is a test case that takes a crazy long time, or forever to complete. Ideally I'd want my run to be aborted after the timeout, but I don't know how I'd implement that in this case.
Third case: Extend the second timeout (for test "three") to 13s so that there is sufficient time after test "two" has timed out and completed as well. Code:
$ TAP=1 ./node_modules/.bin/tap foo.js
# one
ok 1 one potato
# two
not ok 2 Timeout!
# three
ok 3 three potato
# four
ok 4 four
# tests 4
# pass 3
# fail 1
ok 5 foo.js
1..5
# tests 5
# pass 4
# fail 1
I.e., this is as expected.
Theory: The timeout handling for each test case isn't correctly starting the count from when that test case itself is being run... but is starting from the start of the full test suite run (or rather the start of when this test file is being run if there are multiple test files being run).
The text was updated successfully, but these errors were encountered:
Fix#25Fix#23
This moves around some things to make the following changes:
1. Stricter ordering of events. Now a bailout will push a pending
assert event, rather than omitting it.
2. `Subtest` comments are now no longer semantically relevant. They`re
just comments. What makes a child test is having indented non-comment
TAP data.
3. Support for buffered subtests is re-added, and made a bit more
robust.
4. Invalid TAP that causes the parser to end in failure now also adds an
entry in the `failures` array, so it's possible to see what went wrong.
This is a breaking change, because of the semantic changes, but it
should be an easy upgrade for node-tap, its primary consumer. There's a
possibility that it'll break some of the reporting, though, so it's
still very provisional.
First case: one test of four with a 'timeout' setting. Another test has a bogus config object ('xxx' key). This suite as expected.
output:
Second case: Both tests "two" and "three" have a timeout. We expect test two to timeout (as above) and test "three" to complete within its timeout:
output:
IOW, this does NOT work as expected.
On a possibly related note, you can see from the printed timestamps that the test run does not terminate until the 7s "setTimeout" still runs to completion. Say this is a test case that takes a crazy long time, or forever to complete. Ideally I'd want my run to be aborted after the timeout, but I don't know how I'd implement that in this case.
Third case: Extend the second timeout (for test "three") to 13s so that there is sufficient time after test "two" has timed out and completed as well. Code:
Result:
I.e., this is as expected.
Theory: The timeout handling for each test case isn't correctly starting the count from when that test case itself is being run... but is starting from the start of the full test suite run (or rather the start of when this test file is being run if there are multiple test files being run).
The text was updated successfully, but these errors were encountered: