Feature: promises #537
Feature: promises #537
Conversation
|
|
||
| finish(err, 'done'); | ||
| }); | ||
| if (itemResult && itemResult.then instanceof Function) { | ||
| itemResult.then(() => finish(null, 'done'), (err) => finish(err, 'done')); |
There was a problem hiding this comment.
2nd arg is only used in case of error.
|
|
||
| finish(err, 'done'); | ||
| }); | ||
| if (itemResult && itemResult.then instanceof Function) { | ||
| itemResult.then(() => finish(null), (err) => finish(err, 'done')); |
There was a problem hiding this comment.
Thought it was obvious but you don't really need null either, you could just .then(finish ;)
There was a problem hiding this comment.
I thought you might mean that – but that would be incorrect. If the promise resolves with a value, then(finish) would pass the resolve value to finish, which would interpret it as an error!
|
You'll need tests with multiple |
|
Seems like travis hit a timeout on 6c7df4a. |
@Marsup, what do you mean by that? |
|
Promises wrap everything in a try catch, so if finish failed synchronously the promise inside your test would catch it and you'd never know. It's prevented by the setImmediate of finish. |
|
You’re right. Proper promise libraries like Bluebird have built-in protection against such mistakes but the native Any suggestions on how to test for that without pulling in Bluebird or something similar? |
|
For lab's small scope I'd suggest just testing that synchronous throws don't leak into any previous promise returning before/after/it. |
…romise chain of the previous test Thanks to @Marsup for the suggestion.
|
Sorry for the sloppy commits. I accidentally pushed my test of native promise behavior on unhandled rejections. Removed it in 411dc96. |
| const settings = Utils.mergeOptions(this._current.options, options, ['only']); | ||
|
|
||
| const test = { | ||
| path: this._path, | ||
| title: this._titles.join(' ') + ' ' + title, | ||
| title: (this._path.length ? this._titles.join(' ') + ' ' : '') + title, |
There was a problem hiding this comment.
is this meant to be this_path.length or this._titles.length ?
There was a problem hiding this comment.
It’s equivalent, these arrays alway have the same length. I can change it, if you think it’s confusing.
There was a problem hiding this comment.
Isn't it easier to just do this._titles.concat(title).join(' ') ?
|
Maybe we should increase the timeout on this test, it keeps failing on travis. |
|
@Marsup Not caused by this PR, but I can piggyback a fix. |
… because they keep failing on travis CI
|
The JSON reporter test takes about a second on my machine, so I can understand that travis surpasses the 3s mark frequently. |
| @@ -1116,7 +1116,6 @@ describe('Reporter', () => { | |||
| expect(result.lint[0].filename).to.exist(); | |||
| expect(result.lint[0].errors).to.exist(); | |||
| done(); | |||
| done = function () {}; | |||
There was a problem hiding this comment.
I know, but I see no way for it to be relevant unless there’s a bug in Lab.report that causes it to call its callback more than once.
And if such a case exists in Lab.report, I’d prefer this test to fail violently instead of shadowing the problem. Or did I miss something?
There was a problem hiding this comment.
thanks, removing the setting of done is a good move
|
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions. |
Implements #536 and fixes two bugs related to naming tests and setup / teardown blocks at the root level (outside any experiment).