Added Should().Throw(), ThrowAsync() and ThrowWithinAsync() flavors that don’t require a specific exception type #3059
Conversation
…vors that don’t require a specific exception type.
Qodana for .NETIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at [email protected]
|
…() test. Added When_async_method_throws_any_exception_within_timespan_it_should_succeed() test.
|
@Xceed-DelvaJB did you accidentally close the PR? |
Pull Request Test Coverage Report for Build 15834460770Details
💛 - Coveralls |
| } | ||
|
|
||
| [Fact] | ||
| public async Task When_async_method_throws_any_exception_it_should_succeed() |
There was a problem hiding this comment.
🔧We try to use a more fact-based naming convention these days and avoid words like should and when. So in this case Succeeds_for_any_thrown_exception. We also started to group the test cases in nested classes named like the API. See for example CollectionAssertionSpecs. There we even used partial classes to keep things organized.
There was a problem hiding this comment.
Ok for the names and organizing. Take a look at my changes. I might have gone overboard with the nested classes. Let me know if it's presentable.
There was a problem hiding this comment.
Yeah, I'm afraid I've sent you into a rabbit hole. The idea is that we group the tests under the nested classes and use names to represent them based on API or capability, e.g. NotThrowAfterAsync, Actions or NogGenericAsyncFunctions (without the Assertions part). And if we do decide to refactor such a big class we either do that
- In a separate PR
- In a separate commit if your PR has been properly organized into focused commits we want to keep after merging.
In your case, we will squash the PR as you have merged the main branch into the feature branch. We only do rebases.
So let's remove these nested classed you've added so we can look at this at a later point of time.
There was a problem hiding this comment.
No problem, done.
I read your article about source control history and will try to put it to use for the next pull request.
docs/_pages/releases.md
Outdated
|
|
||
| * Clarify the date/time type when comparing non-compatible dates and times in `BeEquivalentTo` - [3049](https://github.com/fluentassertions/fluentassertions/pull/3049) | ||
| * Improve the rendering of exception messages when using `WithMessage` for better readability - [3039](https://github.com/fluentassertions/fluentassertions/pull/3039) | ||
| * Added `Should().Throw()`, `ThrowAsync()` and `ThrowWithinAsync()` flavors that don’t require a specific exception type - [3056](https://github.com/fluentassertions/fluentassertions/issues/3056) |
There was a problem hiding this comment.
🔧 This needs to become part of a new 8.4.0 section.
There was a problem hiding this comment.
Additionally we link to the PR resolving an issue and not the issue itself.
There was a problem hiding this comment.
I should have noticed that. For future reference, I need to create a pull request, then update the release notes files with the number and link?
There was a problem hiding this comment.
Pull Request Overview
Adds non-generic overloads for exception assertions so consumers can assert “any exception” without specifying a type.
- Introduces
Should().Throw()on delegates and actions. - Adds
ThrowAsync()andThrowWithinAsync()on async functions. - Updates release notes and API approvals to reflect the new overloads.
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| docs/_pages/releases.md | Added release note for new Throw()/ThrowAsync()/ThrowWithinAsync() overloads |
| Tests/FluentAssertions.Specs/Exceptions/ThrowAssertionsSpecs.cs | Added unit tests for new non-generic Throw() overload |
| Tests/FluentAssertions.Specs/Exceptions/AsyncFunctionExceptionAssertionSpecs.cs | Added tests for ThrowAsync() and ThrowWithinAsync() |
| Tests/Approval.Tests/ApprovedApi/FluentAssertions/*.verified.txt | Updated approved API files to include new overload signatures |
| Src/FluentAssertions/Specialized/DelegateAssertions.cs | Implemented non-generic Throw() in delegate assertions |
| Src/FluentAssertions/Specialized/AsyncFunctionAssertions.cs | Implemented non-generic ThrowAsync() and ThrowWithinAsync() |
Comments suppressed due to low confidence (3)
docs/_pages/releases.md:16
- Consider adding a new version header (e.g.,
## 8.3.0) above this entry to group the new feature under the correct release section, ensuring consistency in the release notes structure.
* Added `Should().Throw()`, `ThrowAsync()` and `ThrowWithinAsync()` flavors that don’t require a specific exception type - [3056](https://github.com/fluentassertions/fluentassertions/issues/3056)
Tests/FluentAssertions.Specs/Exceptions/ThrowAssertionsSpecs.cs:9
- Add a negative test to verify that invoking
Should().Throw()on a delegate that does not throw any exception results in an assertion failure, covering the failure path for the new overload.
[Fact]
Tests/FluentAssertions.Specs/Exceptions/AsyncFunctionExceptionAssertionSpecs.cs:938
- Add a test case to verify that
ThrowAsync()andThrowWithinAsync()fail as expected when the asynchronous operation does not throw an exception, covering the negative scenario for the new overloads.
[Fact]
docs/_pages/releases.md
Outdated
|
|
||
| * Clarify the date/time type when comparing non-compatible dates and times in `BeEquivalentTo` - [3049](https://github.com/fluentassertions/fluentassertions/pull/3049) | ||
| * Improve the rendering of exception messages when using `WithMessage` for better readability - [3039](https://github.com/fluentassertions/fluentassertions/pull/3039) | ||
| * Added `Should().Throw()`, `ThrowAsync()` and `ThrowWithinAsync()` flavors that don’t require a specific exception type - [3056](https://github.com/fluentassertions/fluentassertions/issues/3056) |
There was a problem hiding this comment.
Additionally we link to the PR resolving an issue and not the issue itself.
Grouped tests in nested classes based on API. Updated some test names to fit with new naming-style.
docs/_pages/releases.md
Outdated
|
|
||
| ## 8.4.0 | ||
|
|
||
| * Added `Should().Throw()`, `ThrowAsync()` and `ThrowWithinAsync()` flavors that don’t require a specific exception type - [3059](https://github.com/fluentassertions/fluentassertions/pull/3059) |
There was a problem hiding this comment.
🔧 This should be placed under the "enhancements" section. See also previous versions.
| } | ||
|
|
||
| [Fact] | ||
| public async Task When_async_method_throws_any_exception_it_should_succeed() |
There was a problem hiding this comment.
Yeah, I'm afraid I've sent you into a rabbit hole. The idea is that we group the tests under the nested classes and use names to represent them based on API or capability, e.g. NotThrowAfterAsync, Actions or NogGenericAsyncFunctions (without the Assertions part). And if we do decide to refactor such a big class we either do that
- In a separate PR
- In a separate commit if your PR has been properly organized into focused commits we want to keep after merging.
In your case, we will squash the PR as you have merged the main branch into the feature branch. We only do rebases.
So let's remove these nested classed you've added so we can look at this at a later point of time.
Put release note in its proper section.
|
Thanks @Xceed-DelvaJB |
This implements issue #3056
IMPORTANT
./build.sh --target spellcheckor.\build.ps1 --target spellcheckbefore pushing and check the good outcomeCONTRIBUTOR LICENSE GRANT
By submitting this contribution, the contributor hereby irrevocably grants to the project owners and maintainers a perpetual, worldwide, royalty-free, irrevocable license to use, reproduce, modify, distribute, sublicense, and create derivative works of the contribution for any purpose and under any terms, including proprietary licensing.
The contributor waives any moral rights in the contribution to the extent permitted by law and agrees not to assert any claim of authorship or control over the contribution. The contributor represents that they are the sole author of the contribution and that it is provided free of any third-party claims.
The contributor understands and agrees that the maintainers may, at their sole discretion, use, license, or redistribute the contribution as part of any work and under any terms they choose, without further permission or attribution.