best way to troubleshoot that is to create a strict mock, it will throw at the call-site that performs that call @weitzhandler
Hi. I'm attempting to use It.Is<> outside of Setup but it seems to be returning null - I assume due to relying on knowing the current method. I was trying to add some code to remove boilerplate where the only thing changing is an argument (and condition expression) to a method call. Something like:
var mockCommandBus = new Mock<ICommandBus>();
mockCommandBus
.Setup(_ => _.PublishAsync(
testCommand,
It.IsAny<CancellationToken>()))
.ReturnsAsync(result);
return (mockCommandBus.Object, mockCommandBus);Called:
CommandBusBuilder.BuildMockCommandCall(
It.Is<RegisterNewApplication>(_ => _.Name == name && _.Description == description),
Result.Ok(new ApplicationId(id)));
In my head it makes sense on paper, but evidently due to how the argument is resolved and expression evaluated, it sort of needs to be inside
Setup. Anyone got any thoughts on this? Alternatives? I'm trying to avoid constantly writing the first block.
@RaringCoder With Moq 4,
It.Is and other matchers only work when used inside LINQ expression tree. What's important is their identity, so to speak, and that is only preserved in a LINQ expression tree. Once evaluated, that is gone and all ypu're left with is their retuen value, which is in fact completely irrelevant & ignored by Moq.
So if you want to avoid boilerplate you'd likely have to create a helper function (possibly parameterized) that creates similar setup/verify expressions for you as a whole. Extracting parts of an expression, then putting them back in somewhere else, means you have to go through the static
Expression.* factory methods which is going to be a pain in the b*tt compared to the C# compiler doing that for you automagically.
@trampster, Moq 4 doesn't (and probably cannot) fully support
Span<T> and other by-ref-like types due to limitations in .NET Reflection and LINQ expression trees. No way around it unfortunately.
There is a Docs folder, but it has very little in it and what is there is confusing and 2 years old.
There also doesn't appear to be a nuget package for it
Also there has only been one commit to it this year and that was in Feb
The readme itself lists the nuget package feed:
> CI package feed: http://kzu.nuget.cloud/index.json (CDN) or https://kzu.blob.core.windows.net/nuget/index.json (blob).
> CI package feed: http://kzu.nuget.cloud/index.json (CDN) or https://kzu.blob.core.windows.net/nuget/index.json (blob).
but unfortunately that simply doesn't perform well for large API surfaces :disappointed:
I tried optimizing it as much as possible using asp.net core but I don't think it's acceptable. So, source generators it is :smile:
(well, will be, just need to find time... but I've been already playing quite a bit with those, so I got a good grasp of what it will take)
Hi all, sorry if this is not the right place for questions like this - please redirect me.
I am updating a solution with around 10,000 tests from Moq 4.7.8 to Moq 4.14.5 and have most issues ironed (<50 failures I can attribute to the upgrade now) out but am stumped by odd behavior with Mock.As<T> where an object implements multiple interfaces and those interfaces define the same property. After setting the property, the object retains the old property value when casted to at least one of the interface versions and each time I correct the failing one, the previously successful one now fails. I am not sure that the changes in the changelog really describe the differences I am seeing.
Is there someone who can help me understand what changed with Mock.As<T> , and help me understand the correct pattern for setting up my mock so the property behaves as intended?
I am updating a solution with around 10,000 tests from Moq 4.7.8 to Moq 4.14.5 and have most issues ironed (<50 failures I can attribute to the upgrade now) out but am stumped by odd behavior with Mock.As<T> where an object implements multiple interfaces and those interfaces define the same property. After setting the property, the object retains the old property value when casted to at least one of the interface versions and each time I correct the failing one, the previously successful one now fails. I am not sure that the changes in the changelog really describe the differences I am seeing.
Is there someone who can help me understand what changed with Mock.As<T> , and help me understand the correct pattern for setting up my mock so the property behaves as intended?
@bluechrism it might help if we had a minimal code example to look at. Can you e.g. boil down one of your failing tests to just two or three interfaces with only one property each, then state your expectatipns (probably whatever would've happened with version 4.7), what happened instead (using the latest version), and why you think that isn't right? If so please post an issue over at https://github.com/moq/moq4.
Hey, before i write up another issue (and a full repro is coming for the other one), can someone explain this difference between new Mock<T> and using Mock.Of<T> with Mock.Get to set up a property: Again, both the Tests would pass with Mock 4.7.8 but the second now fails with 4.14.5.
@bluechrism Looking at the code base 4.14.5 used to setup the mock using the method SetupAllProperties which effectively setup stubs. That means that you would have a real get\set for all the properties. You can avoid that by using MockBehavior.Strict. The only question is why these tests are passing on 4.7.8, seems they should fail there as well...
How do I build moq4? I'm getting the errors above
Hi all, I am one of the maintainers on Moq.AutoMocker. I am wondering if it would be ok to use Moq logo as the icon for the NuGet package. Specifically this one from the org page. I also noticed that the Moq NuGet package does not appear to have a icon set. I would be happy to submit PRs on both projects if that is acceptable.
@ajmcateer - no, that is currently not possible. You'd need to be able to do something along the lines of
sequenceSetup.ReturnsRange(Enumerable.Repeat(lastValue, int.MaxValue)) though that hasn't been implemented. We've briefly discussed this in moq/moq4#573.
Depending on the situation you may be able to work around that by taking advantage of the fact that once exhausted, sequence setups fall back to producing default values. So you could e.g. set up the desired default value using
mock.SetReturnsDefault. (Though take note that this is not specific to one method setup, but to all of a mock's methods.)
@bluechrism, Gitter only just showed me your above post from Sept 3. That's actually a regression (IMO), see moq/moq4#1066.
Worst case is that you'll need to resort to writing a mock class manually for types that use by-ref structs.
Moq 5 has fewer limitations in general because it uses Roslyn to create mock types at compile-time, while Moq 4 generates mock types at runtime using System.Reflection.Emit. Generally speaking, Roslyn, being the default C# compiler, knows about all possible language constructs; in comparison, Reflection hasn't been brought fully up-to-date, and it cannot always deal with certain newer language constructs (such as by-ref structs). So Moq 4 inherits those limitations from Reflection, while Moq 5 is in principle much less constraints.
That being said, I'm not overly familiar with Moq 5. It's entirely possible that it also cannot deal with by-ref structs at this time (I'd have to check) if its API is designed such that invocation
Arguments get boxed as objects (boxing isn't allowed for by-ref structs, i.e. stack-only types). But as far as my current understanding of Moq 5 goes, that at least would be a limitation caused by its own API, and not by the underlying technology.
also probably linq expressions cannot represent ref structs, and params arrays use object boxing...
Reflection does more than just emit IL. Reflection presents you with higher-level abstractions like
Type, MethodInfo etc. Try to do something with the much lower-level System.Reflection.Metadata or Mono.Cecil, and you'll soon see what System.Reflection provides beyond those. Like other parts in the BCL (say, LINQ expression trees, or CodeDOM), Reflection would ideally be updated together with C# language innovation... and that hasn't fully happened for quite a few years now. For example, try DynamicInvoke-ing a delegate that has spans in its signature; or try reflecting over all the custom modifiers that the C# compiler rmits these days. Yes, Reflection isn't the only limiting factor. You're already aware of some LINQ expression tree limitations (no assignment, no async/await, no default parameters, etc.) though Moq 4 can partly work around rhose. But at the end of the day, those parts of the BCL lag behind Roslyn.