Allow to pass a delegate to Wrapping() about fakeiteasy HOT 9 CLOSED

That's correct, yes.

from fakeiteasy.

Congratulations, @drauch! Happy fathering!

On to business. Because I still don't understand, it sounds to me like at the time you decide to swap in the Fake, you already have access to the original service that you'd be wrapping. I'm sure I'm still missing something, because if it were that easy, you wouldn't be here. Still, we at FakeItEasy Canada don't understand the situation in which this feature would apply, nor how far-reaching the benefit would be.

I propose that until you (or maybe one of your teammates, since it sounds like this is a work project) can show up with an example, or very detailed explanation of the flow (which we can ask annoying questions about), we close the issue. And then it can be reopened when there's more information.

from fakeiteasy.

Hi @drauch,

So, if I understand what you're saying, you'd like the ability to lazily resolve the wrapped object. Is that right?

from fakeiteasy.

Hi, @drauch.

I may be missing something, but this seems fairly complicated and maybe a little niche.
Could you provide sample (non-working, of course) code that would demonstrate usage (including as much of a hypothetical system under test as we'd need to understand; could be none)? Then we (I) could understand the intent and we could all discuss it before moving onto considerations of whether the feature is a good fit and how to implement it?

from fakeiteasy.

private IService? service;

...

var fake = A.Fake<IService>(o => o.Wrapping(() => service));
A.CallTo(() => service.Foo()).Returns(5);

...

// Start web app for my web tests here
service = myWebAppContainer.Resolve<IService>();

...

// execute test here, call to service.Bar() is forwarded to real service of web app, call to service.Foo() is handled by the fake

Best regards,
D.R.

from fakeiteasy.

Ah, okay, so @thomaslevesque nailed it. I had interpreted

It would be great to have an overload for Wrapping() that takes a delegate to allow the following:

1. Set up fake object wrapping a delegate that returns a field which is currently null
2. Start the subject-under-test application
3. Obtain the object-to-be-wrapped from the application and save it to the field
4. Any calls to the fake which are not set up are now passed on to the delegate -> to the field

as suggesting that the call would be responsible for managing fields, starting SUTs, obtaining the subject, and so on. But M. Levesque noticed the curial "to allow the following".

The API seems easy to understand with the example. But still the workflow looks weird. I'm going to ask: what's preventing your example from being

var IService service service = myWebAppContainer.Resolve<IService>();

var fake = A.Fake<IService>(o => o.Wrapping(service));
A.CallTo(() => fake.Foo()).Returns(5); // your code had "service" instead of "fake"; I suspect typo. Below as well.

// Start web app for my web tests here

// service.Bar() is forwarded to real service of web app, call to service.Foo() is handled by the fake

Why is it not possible to instantiate the service before configuring the Fake?

Possibly some details were left out of your example, because we don't even see fake being used in the test. Your code "configured" service and then mentioned how it would behave, but I assumed those were typos, and you meant fake. Even with that change, fake is not obviously provided to the system under test (which I don't think even appears in your sample code).

from fakeiteasy.

The web app is started in an NUnit.SetUpFixture() method, the fake should only be used in some tests, so the order would be as follows in our tests:

1. NUnit.SetUpFixture: Set up container for web app with `o.Wrapping(_ => _fake ?? _originalService)
2. NUnit.SetUpFixture: Start web app
3. NUnit.TestFixture.SetUp: Set fake + A.CallTo() expectations if necessary for the test

Best regards,
D.R.

from fakeiteasy.

Thanks, @drauch. I feel like I'm almost there. But not quite.

You have a container that you can pre-register a dependency (I assume of a particular type), so you pre-register the Fake<Service> that will wrap a not-yet-created concrete Service object.
Then when you start up the web app, it instantiates the Service object and stores it in _originalService? But the web app will be using the Fake<Service> object, because that was what was registered? Why did the container bother creating the concrete Service object when it was already supplied with the Fake<Service> object? Wouldn't that have satisfied its need for a Service-like object?

I feel like some actual code would help me out.

from fakeiteasy.

We create a wrapping fake just for the "branching" between a fake and the original service. So we can use either the original or a fake in each unit test.

I can't copy in our code due to company policies, sorry :-/ Maybe if I find the time I can create a minimal repro sample, but I've become a father two months ago and time is very sparse at the moment ;-)

Best regards,
D.R.

from fakeiteasy.