Skip to content

refactor: use jasmine expectAsync instead of try/catch in tests #18535

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

devversion
Copy link
Member

Currently tests that assert errors to be thrown/or not from
asynchronous methods use try/catch in order to use await.

We added a helper method for this in the private testing utilities. This
one reduced the try/catch burden. That helper method has downsides
though because it doesn't allow us to expect no error to be thrown.

We should remove this method in favor of using jasmine's expectAsync
function. This one gives us more flexibility and is also more
"jamsine"-idiomatic.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Feb 18, 2020
@devversion devversion force-pushed the refactor/use-jasmine-expect-async branch 7 times, most recently from 9cb859e to 30eb1c5 Compare February 19, 2020 13:32
@devversion devversion marked this pull request as ready for review February 19, 2020 14:09
@devversion devversion added blocked This issue is blocked by some external factor, such as a prerequisite PR pr: merge safe target: patch This PR is targeted for the next patch release labels Feb 19, 2020
@@ -156,6 +156,8 @@
},
"resolutions": {
"dgeni-packages/typescript": "3.7.4",
"@bazel/jasmine/jasmine": "3.5.0",
"@bazel/jasmine/jasmine-core": "3.5.0",
Copy link
Member Author

Choose a reason for hiding this comment

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

These are temporarily until @bazel/jasmine has been updated to jasmine v3.5.0. I created a ticket for tracking: DEV-37, and also sent a PR upstream to update jasmine.

Currently tests that assert errors to be thrown/or not from
asynchronous methods use `try/catch` in order to use `await`.

We added a helper method for this in the private testing utilities. This
one reduced the `try/catch` burden. That helper method has downsides
though because it doesn't allow us to expect no error to be thrown.

We should remove this method in favor of using jasmine's `expectAsync`
function. This one gives us more flexibility and is also more
"jamsine"-idiomatic.
@devversion devversion force-pushed the refactor/use-jasmine-expect-async branch from 30eb1c5 to 8b8c980 Compare February 19, 2020 14:23
@devversion devversion removed the blocked This issue is blocked by some external factor, such as a prerequisite PR label Feb 19, 2020
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

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

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Feb 19, 2020
@mmalerba mmalerba added action: merge The PR is ready for merge by the caretaker and removed action: merge The PR is ready for merge by the caretaker labels Feb 19, 2020
@andrewseguin andrewseguin merged commit 19de0bd into angular:master Feb 20, 2020
andrewseguin pushed a commit that referenced this pull request Feb 20, 2020
Currently tests that assert errors to be thrown/or not from
asynchronous methods use `try/catch` in order to use `await`.

We added a helper method for this in the private testing utilities. This
one reduced the `try/catch` burden. That helper method has downsides
though because it doesn't allow us to expect no error to be thrown.

We should remove this method in favor of using jasmine's `expectAsync`
function. This one gives us more flexibility and is also more
"jamsine"-idiomatic.

(cherry picked from commit 19de0bd)
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants