Get instance of inner Interface created by AutoMoqData.
See original GitHub issueHi,
I’m trying to get the instance of the the inner Mocked Interface created by AutoMoqData to setup the interface.
Is there a way to do something like this
[Theory, AutoMoqData]
public void Dummy(IFixture fixture, ComplexClassWithInnerInterface sut)
{
fixture.GetInstance<IInnerInterfaceMockCreatedByAutoMoqData>().Setup(x => x.Method).Result(something);
Assert.Equal(String.Empty, String.Empty);
}
Thanks
Issue Analytics
- State:
- Created 5 years ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
An inner class, an outer interface, how to get an access?
In this case you can use anonymous inner class. As you can't instantiate any interface it is impossible to access their methods. Interfaces...
Read more >A Guide to Inner Interfaces in Java
A quick and practical guide to inner interfaces in Java. ... Get started with Spring 5 and Spring Boot 2, through the Learn...
Read more >Nested Interface in Java
We can declare interfaces as members of a class or another interface. Such an interface is called a member interface or nested interface....
Read more >Autofixture can't create instance of PageData
I'm running into a problem with Autofixture not able to create instances of PageData (or derived types) due to an error: AutoFixture.
Read more >AutoFixture, xUnit.net, and Auto Mocking - Nikos Baxevanis
In the test method below we would like to use xUnit.net data theories to provide: Auto-generated data specimens for d , s ,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks @xlecoustillier for the great answer. Basically, I’d suggest to do the same as I’m constantly following this pattern in my tests.
Well, this argument looks a bit weird. Probably, it’s something wrong with the design of tested code if you need to configure 30 dependencies to make a scenario 😟 I’m 99% @ploeh would suggest you to review the code first before proceeding further, as per his advice it’s recommended to have max 3-4 dependencies 😅
I’m not 100% sure I understood the entire message clearly, but from what I got you are right. By default all the generated objects are transient and
fixture
doesn’t preserve them. If you wish to make the particular object a singleton, you should use thefixture.Freeze<>()
API or[Frozen]
attribute or any other suitable API. The existing default behavior was designed to cover the common scenarios and in most cases you don’t want to have the same object per type.If you are still looking for the help from our side, please provide more exact requirement you have. Better, share enough code to demonstrate the current limitations and goal you would like to achieve - that will help to sync better 😉
Thanks.
In this case you’ll have to freeze the mock to ensure that the instance you generate will also be injected into the sut:
Be careful to always create the frozen mocks before the sut so that they already exist when the sut gets created and therefore get correctly injected.
See ploeh’sblog for reference.