Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

chore: remove try-catch from tests where functions are async #2531

Merged
merged 9 commits into from
Oct 15, 2019

Conversation

achingbrain
Copy link
Member

We had a few instances in the tests where assertions may be missed due to functions not throwing where we thought they would so this PR refactors that code to use .then(onResult, onReject) instead.

Follows on from #2514 (comment)

We had a few instances in the tests where assertions may be missed
due to functions not throwing where we thought they would so this
PR refactors that code to use `.then(onResult, onReject)` instead.

Follows on from #2514 (comment)
expect(err.killed).to.be.true()
expect(stdout).to.include('Daemon is ready')
}
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These look equivalent to me - am I missing something?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, you're not missing anything - it was more an attempt at consistency with other tests that have been refactored to be more rigorous.

Copy link
Member

@alanshaw alanshaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look ok to me, I'm just not sold on mixing await and .then. To me this reads like there's something weird going on that warrants falling back to using .then when that's not true in most cases here.

IMHO we should only use .then if we really have to. Using it when it's not absolutely required sets a precedent for contributors that using .then is ok, when actually we strongly prefer using await.

@achingbrain
Copy link
Member Author

The await something().then(failOnResolve, expectOnReject) approach was something @jacobheun recommended here.

I don't mind either way, but if we're going to go back & forth on this, something should be added to CONTRIBUTING_JS.md to settle the matter.

@jacobheun
Copy link
Contributor

I'm not a huge fan of mixing the two either, but I think it has it's place. Tests where you expect failures are a place I find them useful, because IMO it helps prevent false positive tests. It's very easy to forget to throw or add the expect.fail after a try/catch (I've already seen this happen quite a bit).

@alanshaw
Copy link
Member

Ah ok now I understand - would an assertion like https://github.com/avajs/ava/blob/master/docs/03-assertions.md#throwsasyncthrower-expected-message be the solution then?

@achingbrain
Copy link
Member Author

achingbrain commented Oct 15, 2019

We could do this sort of thing instead?

await expect(promise)
  // where we assert on the error type
  .to.eventually.be.rejectedWith(TypeError)

  // or where we assert on the exact error (e.g. when stubbing)
  .to.eventually.be.rejectedWith(someErrInstance)

  // or where we assert on the error message
  .to.eventually.be.rejectedWith(Error, /match regex or could be string/)

  // or where we do expect(err).to.be.ok(); expect(err.code).to.equal('...')
  .to.eventually.be.rejected()
  .with.property('code', 'ERR_A_CODE')

@achingbrain achingbrain merged commit 220d1f0 into master Oct 15, 2019
@achingbrain achingbrain deleted the remove-try-catch-from-tests branch October 15, 2019 09:52
achingbrain added a commit that referenced this pull request Oct 15, 2019
* chore: remove try-catch from tests where functions are async

We had a few instances in the tests where assertions may be missed
due to functions not throwing where we thought they would so this
PR refactors that code to use `.then(onResult, onReject)` instead.

Follows on from #2514 (comment)
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 this pull request may close these issues.

3 participants