-
Notifications
You must be signed in to change notification settings - Fork 21
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
AutoMock.Mock<T> doesn't use constructor with parameters #42
Comments
Sorry it seems this isn't working. I'm honestly not sure exactly what's up off hand but wanted to get back to you in a timely fashion to say... Likely we won't be getting to look at this in a timely fashion. Any help you can provide up front to step into the code with Source Link (there's not much code in this library) and pinpoint the issue... or even get a PR together... will go a long way. There are an unfortunately low number of folks available at the moment to troubleshoot stuff, and most of the time we have is dedicated to core Autofac and more frequently used extensions and doc. I wish that wasn't the case, but it kind of is what it is at the moment. I just didn't want you sitting waiting for a solution that won't be coming that quickly. Again, sorry. |
@tillig thank you for your transparency and honesty! Because there is a workaround, this isn't a huge deal for me. I will try and find some time to dig into this, I appreciate that this is a secondary library. |
Took a look at this briefly this morning; there may be a change that can be made to pass arguments through to Moq, so it uses provided parameters, and your test will pass. I have two concerns here however; first, we would be conflating the Autofac var argumentsToMoq = new List<object>();
foreach (var providedParam in parameters)
{
if (providedParam is ConstantParameter constParam)
{
argumentsToMoq.Add(constParam.Value);
}
} This isn't ideal, and I can imagine a variety of confusing situations where constructors don't match unexpectedly. Secondly, the purpose of accepting parameters in the I wonder if in your specific use-case @msft-mw, you should just register your mock directly into the container, like so: var myMock = new Mock<AbstractType>(8);
myMock.Setup(q => q.DoThing()).Returns(16);
using (var mocks = AutoMock.GetLoose(cfg => cfg.RegisterMock(myMock)))
{
AbstractType instance = mocks.Create<AbstractType>();
Assert.Equal(16, instance.DoThing());
} |
@alistairjevans thank you for investigating, and I agree that it could be a bit confusing behaviour-wise with how Moq actually works. Given the confusion that could come up if a user passed The workaround you suggest below was what I landed on as well, it's good to have it validated as a solution. Lastly, if you don't mind, could you explain this a bit more?
I always thought that when a type couldn't be mocked, that I should use |
Describe the Bug
Parameters passed when getting a mock from an
AutoMock
aren't used and instead mocking fails trying to find a parameter-less constructor.Steps to Reproduce
Expected Behavior
I expected the
TypedParameter
to be used so that the mock is constructed. I recognize that the point of the mock is to ignore the value I provided, which is fine, and that's what I'm using theSetup
for, but the inability to create the mock in the first place is what is confusing to me. I can manually mock the type usingAnd it will succeed, and I can then put the mock inside the
AutoMock
to later resolve. It's very possible that this isn't supposed to work and I'm not understanding the documentation!Exception with Stack Trace
Dependency Versions
Autofac: 6.0.0
Autofac.Extras.Moq: 6.0.0
Microsoft.NET.Test.Sdk: 16.9.4
MSTest.TestAdapter: 2.2.3
MSTest.TestFramework: 2.2.3
coverlet.collector: 3.0.3
Additional Info
The text was updated successfully, but these errors were encountered: