Open Jason31569 opened 2 months ago
Agree it reads better, but the trade-off is that we're adding yet another extension method on object
(bloats intellisense/autocomplete). We could potentially have in NSubstitute.Extensions
so people could opt-in 🤔 .
Another option is to use the existing .Returns
overload with a call back to "do and return".
Agree it reads better, but the trade-off is that we're adding yet another extension method on
object
(bloats intellisense/autocomplete). We could potentially have inNSubstitute.Extensions
so people could opt-in 🤔 .
Maybe the NSubstitute.Extensions
option is the way to go
Another option is to use the existing
.Returns
overload with a call back to "do and return".
Are you talking about one of these methods?
ConfiguredCall Returns<T>(this T value, Func<CallInfo, T> returnThis, params Func<CallInfo, T>[] returnThese)
ConfiguredCall Returns<T>(this Task<T> value, Func<CallInfo, T> returnThis, params Func<CallInfo, T>[] returnThese)
ConfiguredCall Returns<T>(this ValueTask<T> value, Func<CallInfo, T> returnThis, params Func<CallInfo, T>[] returnThese)
Yes those Returns
overloads take Func
s which let us do then return.
Referencing issue #98...
While doing something like
stuffDoer.Calculate().Returns(42).AndCalls(x => blah());
works, it is would make a lot more sense to be able to do something likestuffDoer.Calculate(something).Do(x => { }).Returns(42);
insteadTake the below example
Because execution is from left to right a=[8, 10], and b=[4, 6, 8, 10]
We are used to reading (and even expecting) statements to work from left to right. Someone new to NSubstitute (like myself) could find this confusing, and would not expect the trailing Do to run before the Returns