Question: What am I missing here? about asynckeyedlock HOT 5 CLOSED

Hi,

For completeness sake, can you please include the rest of the class, showing the initialization of SUT?

from asynckeyedlock.

I believe you may have hit on exactly the problem. SUT is created by Moq.Automocker. It's not a mock itself, but any of its dependencies would be, and maybe that's where things are going wrong. The automocker is going to pick the greediest constructor, so it should have settled on the one that takes options, concurrencyLevel, capacity, and a comparer. Since it will have mocked these all out, we can probably assume that at the very least, the mocked comparer is what's throwing it off. Inlining the creation of the locker and taking the default options makes it behave.

Thanks for pointing me in the right direction.

from asynckeyedlock.

I have a follow-up question, though. At runtime, the .Net IoC is also going to try to grab the greediest constructor. I haven't looked at the internals of the .Net IoC, but could this cause similar issues if it picked the wrong one?

from asynckeyedlock.

Wouldn't you usually set that up as a singleton via IoC?

from asynckeyedlock.

In the "real world", yes, but the problem I was having was in writing a unit test to document the behavior we're using. Because our tests are using an auto-mocker to create the system under test, and because it always picks the greediest constructor, it was mocking out the comparer, which then threw off the test results. Manually creating the system under test was the fix I needed.

from asynckeyedlock.