Skip to content

Implement shouldNotThrow matchers#603

Merged
LeoColman merged 1 commit into
masterfrom
feature/205-add-shouldNotThrow-matchers
Jan 22, 2019
Merged

Implement shouldNotThrow matchers#603
LeoColman merged 1 commit into
masterfrom
feature/205-add-shouldNotThrow-matchers

Conversation

@LeoColman

Copy link
Copy Markdown
Member

This commit implements shouldNotThrow, shouldNotThrowExactly and shouldNotThrowAny matchers, with their Unit variations.

Effectively, for the user, it doesn't make a difference on calling this and calling the code directly, but this may be better for communicating intent explicitly.

These matchers won't let an uncaught failure to be silently caught. Any uncaught exception will still be propagated upwards, however, if it matches the shouldThrow<T> T parameter, it will be wrapped around an AssertionError (makes tests Yellow, not Red.).

It's never necessary to use this construct. It would be the same as every java method being void foo() throws no Exception, and it usually doesn't make sense to.

Fixes #205

@LeoColman LeoColman self-assigned this Jan 22, 2019
@LeoColman LeoColman requested a review from sksamuel January 22, 2019 17:58
@LeoColman

Copy link
Copy Markdown
Member Author

Note that documentation is purposefully not updated, as this isn't a real feature. Following our conventions that Every should have a shouldNot, this is just a small fix.

@LeoColman

Copy link
Copy Markdown
Member Author

@sksamuel
If you could give the javadocs a very quick read... I copy-pasted most of it, and maybe there's a small slip

Comment thread kotlintest-assertions/src/main/kotlin/io/kotlintest/AnyThrowableHandling.kt Outdated
This commit implements `shouldNotThrow`, `shouldNotThrowExactly` and `shouldNotThrowAny` matchers, with their `Unit` variations.

Effectively, for the user, it doesn't make a difference on calling this and calling the code directly, but this may be better for communicating intent explicitly.

These matchers won't let an uncaught failure to be silently caught. Any uncaught exception will still be propagated upwards, however, if it matches the `shouldThrow<T>` T parameter, it will be wrapped around an AssertionError (makes tests Yellow, not Red.).

It's never necessary to use this construct. It would be the same as every java method being `void foo() throws no Exception`, and it usually doesn't make sense to.

Fixes #205
@LeoColman LeoColman force-pushed the feature/205-add-shouldNotThrow-matchers branch from 058834f to cd21fa1 Compare January 22, 2019 18:05
@LeoColman

Copy link
Copy Markdown
Member Author

Merging when this gets green.

@LeoColman LeoColman merged commit aceb69f into master Jan 22, 2019
@LeoColman LeoColman deleted the feature/205-add-shouldNotThrow-matchers branch January 22, 2019 19:02
* **Attention to assignment operations:**
*
* When doing an assignment to a variable, the code won't compile, because an assignment is not of type [Any], as required
* by [block]. If you need to test that an assignment doesn't throw a [Throwable], use [shouldNotThrowAnyUnit] or it's

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

*its

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants