Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Daniel Hughes
    @trampster
    Also there has only been one commit to it this year and that was in Feb
    What is the status of Moq 5 development? is it mostly complete, are there plans to release it in the near future?
    Daniel Cazzulino
    @kzu
    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).
    Daniel Hughes
    @trampster
    OK I see, thats why I couldn't find it, it's not published to nuget.org
    Daniel Cazzulino
    @kzu
    no near future plans. I've been too busy :disappointed:. Also, for the proxy codegen, I plan on switching to roslyn source generators, coming in .net5 timeframe.
    Daniel Hughes
    @trampster
    I love the idea of using source generators
    Daniel Cazzulino
    @kzu
    yeah, in the repo currently, I have it based on AutoCodeFix and build-time generators
    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)
    bluechrism
    @bluechrism
    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?
    Dominique Schuppli
    @stakx
    @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.
    bluechrism
    @bluechrism
    OK, I'll work out a minimal set and can post it up as an issue.
    bluechrism
    @bluechrism
    image.png
    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.
    Nikola Radin
    @lepijohnny
    @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...
    bluechrism
    @bluechrism
    @lepijohnny is you comment about SetupAllProperties referencing Mock.Of<T> then?
    Nikola Radin
    @lepijohnny
    @bluechrism Ah, sorry, my post is indeed confusing :). Mock.Of<T> uses SetupAllProperties(if not MockBehavior.Strict) under the hood. This means all properties will be stubbed. This is the reason why 2nd example fails.
    bluechrism
    @bluechrism
    @lepijohnny Thanks for the clarification.
    Shimmy
    @weitzhandler
    image.png
    image.png
    How do I build moq4? I'm getting the errors above
    Kevin B
    @Keboo
    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.
    Dominique Schuppli
    @stakx
    Hey @Keboo - IMO a PR for the package icon would be great! :+1:Regarding your first question (using the icon for your package) my suggestion would be to use a slightly modified icon for third-party packages... but this is ultimately @kzu's decision.
    ajmcateer
    @ajmcateer
    Hey with Setup Sequence I have specified 4 return values, If I call a 5th time it returns null, is there anyway to make it return the last value forever?
    Dominique Schuppli
    @stakx
    @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.)
    Dominique Schuppli
    @stakx
    @bluechrism, Gitter only just showed me your above post from Sept 3. That's actually a regression (IMO), see moq/moq4#1066.
    Michał Zegan
    @webczat
    question: there is no way to mock methods or verify methods that take spans as parameters? I may really need that. fortunately most tests related to these would just test for return value correctness, but
    Dominique Schuppli
    @stakx
    @webczat This is definitely not possible with Moq 4.x and there's nothing we can do about that. It might be feasible with Moq 5.
    Worst case is that you'll need to resort to writing a mock class manually for types that use by-ref structs.
    Michał Zegan
    @webczat
    what would moq5 change in this respect?
    Dominique Schuppli
    @stakx
    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.
    Michał Zegan
    @webczat
    well but reflection.emit generates IL so it is not something that needs to be updated too much
    also probably linq expressions cannot represent ref structs, and params arrays use object boxing...
    Dominique Schuppli
    @stakx
    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.
    TL;DR: Moq 4 has some hard limits on what it can support. Moq 5 has limits too (though I don't know them precisely myself) but you at least have a chance there when it comes to spans.
    Michał Zegan
    @webczat
    aren't these modifiers actually attributes or so? as for dynamic invoking delegates how could you make such an api even at reflection side if you cannot box spans?
    also many of this is pretty logical, as in, reflection is not a c# specific api. it shouldn't technically get most of these... even some things it already got I'd say. it cannot recognize operators for example can it?
    as for code dom I think this api is ... hmm deprecated?
    Daniel Cazzulino
    @kzu
    hi there folks!
    What does everyone think about moving the community support over to Discord? moq/moq4#1089
    Dominique Schuppli
    @stakx
    My trigger finger merged your PR before I saw thid post. :-D But if you're more active on Discord than here, then moving makes good sense. :+1:
    If we do move for good, would there be any way of making this chat read-only / archived after adding a final redirection message?
    Daniel Cazzulino
    @kzu
    Good point. I'll investigate if that's possible
    Michał Zegan
    @webczat
    @stakx it seems like you are able to create expression tree for a lambda accepting a span when using factories on Expression instead of just letting the compiler construct it.
    Dominique Schuppli
    @stakx
    @webczat that's interesting, I didn't know that. But where to from from there? The underlying code generation & interception strategy still don't support spans. Plus manually constructing expression trees isn't user-friendly at all, that's not really a feasible approach for using Moq from the end-user perspective. ;-(
    Michał Zegan
    @webczat
    yeah. I discovered you can do that so started to think if one could make some kind of helpers or something, but there would likely be problems along the way, spans cannot be generic arguments, etc, so not sure if the rest of moq would happily work with them if I handcrafted such a tree