-
Notifications
You must be signed in to change notification settings - Fork 649
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
Implement shouldNotThrow matchers #603
Conversation
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. |
@sksamuel |
kotlintest-assertions/src/main/kotlin/io/kotlintest/AnyThrowableHandling.kt
Outdated
Show resolved
Hide resolved
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
058834f
to
cd21fa1
Compare
Merging when this gets green. |
* **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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*its
This commit implements
shouldNotThrow
,shouldNotThrowExactly
andshouldNotThrowAny
matchers, with theirUnit
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