Skip to content
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

Add support for calling the wrapped object's method #1717

Closed
thomaslevesque opened this issue Nov 26, 2019 · 3 comments · Fixed by #1718
Closed

Add support for calling the wrapped object's method #1717

thomaslevesque opened this issue Nov 26, 2019 · 3 comments · Fixed by #1718

Comments

@thomaslevesque
Copy link
Member

Currently, when using a wrapping fake like this:

var foo = A.Fake<IFoo>(o => o.Wrapping(new Foo()));

There's no way to explicitly call the method of the wrapped object. It's the default behavior, but as soon as a call is configured, this behavior is lost and there's no way to restore it. For instance, if we do this:

A.CallTo(() => foo.Bar()).Invokes(() => DoSomething());

The Bar method will return a default value, instead of the value from the wrapped object.

A possible workaround is to do something like this:

var realFoo = new Foo();
var foo = A.Fake<IFoo>(o => o.Wrapping(realFoo));
A.CallTo(() => foo.Bar()).Invokes(() => DoSomething()).ReturnsLazily(() => realFoo.Bar());

It's reasonably simple in this specific case, but if the method had arguments it would be much uglier.

A better alternative would be to introduce a new CallsWrappedMethod method:

var foo = A.Fake<IFoo>(o => o.Wrapping(new Foo()));
A.CallTo(() => foo.Bar()).Invokes(() => DoSomething()).CallsWrappedMethod();

CallsWrappedMethod would throw if the fake is not a wrapping fake, of course.

@blairconrad
Copy link
Member

Note that this feature was previously discussed in #805 (comment) by our own @thomaslevesque and more recently by valued community member @asgerhallas in #1693.

@blairconrad blairconrad added this to the vNext milestone Nov 26, 2019
@blairconrad
Copy link
Member

Labelling as breaking because it will force an update to the interfaces that provide the fluent API. Optimistically putting in milestone vNext, because it's currently slated to be 6.0.0, and it would be nice to get our breaking changes in now.

@afakebot
Copy link

This change has been released as part of FakeItEasy 6.0.0-beta.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants