-
-
Notifications
You must be signed in to change notification settings - Fork 548
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
Support assertions for methods returning ValueTask and ValueTask<T> #1158
Support assertions for methods returning ValueTask and ValueTask<T> #1158
Conversation
If we start to support We should also make sure that we follow the guidelines about usage of
|
Non-generic ValueTask is indeed supported in my PR. The "Awaiting" assertions don't change the return types though, and call AsTask just once, so it's safe according to the guidelines you quoted. |
So what's the status of this PR? |
Sorry, did I miss something you want me to change? Do you consider this change useful? |
I think we should do this one. @jnyrup are your concerns addressed in a satisfactory way? |
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.
ValueTask<T>
is available since Net Core 1.0 / .Net Standard 2.1ValueTask
is available since Net Core 2.1 / .Net Standard 2.1
Which matches availability of Span<T>
(#902 )
With the proposed changes in TargetFrameworks
NetCore30.Specs changes from netcoreapp2.1
to netcoreapp2.1
TargetFramework
, but already tested via NetCore20.Specs
leaving netstandard2.1
untested.
Would any be left out, if we only add netcoreapp2.1
? (Xamarin, UWP, ???)
The limitation remarks are handled by calling AsTask()
a you mention.
Not sure if I understand you correctly, but if we switch the NetCore20.csproj to NetCore21.csproj, we should be fine right. We don't have to have to directly test .NET Standard 2.1. That's a compiler concern./ |
If we change NetCore20.Specs to NetCore21.specs, then nothing tests the |
And since that one is no longer supported by Microsoft, I think that is fine. |
Pushed 3 more commits to address the required changes. Not sure I understood your intentions correctly though.... |
Apparently Nuke doesn't like it... |
It's not Nuke, it's XUnit |
It's not a failed test though....is it ? |
Try to run the |
It was due to the Nuke build script. Fixed by 9182d19. |
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.
And since that one is no longer supported by Microsoft, I think that is fine.
We're still supporting net45, even though it's been EOL for almost four years.
@@ -735,6 +989,29 @@ public void When_async_method_of_T_succeeds_and_expected_not_to_throw_particular | |||
action.Should().NotThrow(); | |||
} | |||
|
|||
#if NETCOREAPP2_1 || NETSTANDARD2_1 |
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.
NETSTANDARD2_1
-> NETCOREAPP3_0
four times in this document
We'll drop the explicit .NET Core 2.0 target, but we're still supporting it through our .NET Standard 2.0 target. I might be wrong, but I didn't see anything specifically using .NET Core 2.0 stuff. |
@dennisdoomen the following does not work with
|
You've tried? If so, that's annoying. Maybe we should then just target both. We'll clean-up the targets with 6.0 anyway/ |
I just took master and changed the target framework from |
Got a little bit lost on direction here....if you need any additional work in this PR, just @ me. Otherwise I think you know better which targets to support and not support in the future... |
@jnyrup I propose we keep the changes in the PR and merge it. We'll clean up the targets in 6.0 anyway. |
@danielcweber Sorry for the confusion about the targets. Just to be sure, let's have both:
|
Just so I don't forget about it:
|
There was some odd "this thing took 300ms too long" test fail. Test went well now. But there's maybe a flaky test around. |
@danielcweber It's the test that keeps on giving... #1085 |
@danielcweber if you update the docs as @jnyrup request, we should be ready to merge it. |
^ |
@danielcweber Could you update the index.html line 53 as well? |
Must have slipped through. |
@danielcweber Thanks for contributing this! |
Explicitly take netcoreapp2.1 and netstandard2.1 into account in FluentAssertions.csproj.