feat: update Because method to handle null reason#973
Merged
Conversation
|
Contributor
🚀 Benchmark ResultsDetails
|
Contributor
Test Results 23 files + 10 23 suites +10 7m 43s ⏱️ + 3m 54s Results for commit fbc2cb9. ± Comparison against base commit 01e9240. This pull request removes 1582 and adds 3174 tests. Note that renamed tests count towards both.This pull request skips 1 test. |
Contributor
👽 Mutation ResultsaweXpectDetails
The final mutation score is NaN%Coverage Thresholds: high:80 low:60 break:0aweXpect.CoreDetails
The final mutation score is 97.67%Coverage Thresholds: high:80 low:60 break:0 |
github-actions Bot
added a commit
that referenced
this pull request
May 31, 2026
… null reason (#973) by Valentin Breuß
github-actions Bot
added a commit
that referenced
this pull request
May 31, 2026
… null reason (#973) by Valentin Breuß
vbreuss
added a commit
that referenced
this pull request
May 31, 2026
The synchronous `Because(string?)` overloads were already updated (#973) to ignore null or empty reasons. This applies the same behavior to the asynchronous `Because(Task<string>)` overloads. The async overloads now accept `Task<string?>`, mirroring the nullable `string?` of the synchronous variants: the task reference is still required, but the value it resolves to may be null or empty. When the resolved value is null or empty, the reason is ignored (no `because` text is appended) instead of throwing a `NullReferenceException` (from `reason.Trim()`) or producing a dangling ", because " fragment. Because the resolved string is only available after awaiting, the null/empty guard lives in `AsyncBecauseReason.ApplyTo`, where the result is left unchanged when the reason resolves to null or empty. **Changes:** - `ExpectationResult.Because` and `ExpectationResult<TType, TSelf>.Because` now take `Task<string?>`. - `ExpectationBuilder.AddReason` and `AsyncBecauseReason` updated to `Task<string?>`; the resolved value is checked for null/empty. - Regenerated the public-API approval files for all target frameworks. - Added tests covering null and empty resolved reasons for both the non-generic and generic async overloads.
Contributor
|
This is addressed in release v2.35.0. |
This was referenced Jun 8, 2026
This was referenced Jun 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates the
Becausemethod to gracefully handlenulland empty reasons instead of throwing.Previously, calling
.Because(null)would throw aNullReferenceException(the reason was passed straight intoBecauseReason, which callsreason.Trim()), and an empty string produced a dangling", because "fragment. Now bothnulland empty reasons are simply ignored.Changes
ExpectationResult.BecauseandExpectationResult<TType, TSelf>.Becausenow acceptstring?and skip adding the reason when it isnullor empty.<remarks>note describing the null/empty behavior.net8.0,net10.0,netstandard2.0) to reflect thestring?signature.aweXpect.Core.Api.Tests'AcceptApiChangesas[Explicit], consistent withaweXpect.Api.Tests, so the API-regeneration helper no longer runs as part of the normal test suite (verification still happens inApiApprovalTests).Behavior
.Because("reason").Because("")", because ".Because(null)NullReferenceException