Support Async<'Testable>
& Task<'Testable>
#694
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.
@kurtschelfthout This is basically just the code from my comment here. Upon further thought and experimentation, I think it might actually be valid, if not terribly elegant—but perhaps there is something that I still do not understand and that the tests do not cover. It essentially hinges on whether what I am doing with
Shrink.getValue
inside ofGen.promote
(after applyingrunner
) is valid in all scenarios.Fixes #684.1
Add support for
Async<'Testable>
andTask<'Testable>
as first-class testables.That is,
Async<'Testable>
andTask<'Testable>
are now valid testables for any valid instantiation of'Testable
, just asLazy<'Testable>
,Gen<'Testable>
, or'Generatable -> 'Testable
already were.Footnotes
Note that this is technically a breaking change in that it breaks the example added in Enable properties that return Task<'a> #634. An explicit upcast to non-generic
Task
(… :> Task
) will now be needed for tests involvingTask<'T>
where'T
is not itself a testable type to pass. This matches the behavior for the unwrapped equivalent:The behavior originally desired in Allow asynchronous tests to run on Task<'a> #633 for
Task<unit>
is, however, kept: an upcast fromTask<unit>
toTask
is not required, sinceunit
is a testable type. ↩