Coverage remained the same at 100.0% when pulling 2bad6aa on benhormann:unhandled-promise-rejection into dd0b530 on evilsoft:master.

Thanks for contributing, sorry this slipped under my radar and it's been 10 days.

I'd be curious to understand "what gives" if the promise remains un-handled? Or said differently, what led you to seeing this issue and what insight/value do we gain from handling it?

This is more to be informed in the future, on the base of this i don't see a reason not to approve

Node's default is to emit Event: 'unhandledRejection' and a deprecation warning. The warning mentions In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.; You can turn on this behaviour with --unhandled-rejections=strict.

It really only matters if the default or CI / test runner settings change.

I discovered it in the output of npm run test, it is hidden when using spec:dev.

On second thought, it might look better like this?

  const rejected = Promise.reject(0)
  rejected.catch(() => 'Handle promise rejection, avoid error.')

  t.equal(isPromise(Promise.resolve(0)), true, 'returns true when passed a resolved promise')
  t.equal(isPromise(rejected), true, 'returns true when passed a rejected promise')

Thanks for the extra context. I am a big fan of the arrange, act, assert structure so i like the second option. That being said, both handle the raised issue. I'm happy to approve as is or your welcome to change. I'll leave it to you

@evilsoft it appears travis doesn't want to play ball again, Is it because of a force-push?

Would rebasing onto the previous commit help?

If this project squashes PR commits by default, may I suggest a note about it (and avoiding force pushes) in CONTRIBUTING?

Oh snap, so sorry I missed this @dalefrancis88
Looks like it just did not update, But this is all fixed up and 🔴 👁️ to merge when you want.

@benhormann GREAT catch on this btw, thanks you so much for your time and effort!