General

I suggest you ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  1. Make callbacks more flexible about the required parameters

    Sometimes you don't need all the parameters of the mocked method in the callback. Sometimes you don't need any of them.

    Is it possible to allow partial matches, I'm thinking if there are 4 parameters on the method, and only 3 on the callback, if the first 3 match then allow that callback.

    As the callback verification seems to be done at run time I think this should be possible.

    8 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      1 comment  ·  Admin →

      what should be the batching behavior? Argument type obviously, but what about ordering? What if the method has 2 string parameters mixed with other types?

    • Add reporting to to mocks, outputing as much information as possible for every method invoked

      When your debugging or simply trying to understand what is happening it would be very useful if we could get a list of all the methods that were invoked on a particular mock (or all mocks from a factory)

      This could either be in the form of an explicit call:

      mock.Report();

      or as part of the ToString():

      Console.Writeline(mock.ToString());

      6 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        I agree to the terms of service
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        1 comment  ·  Admin →

        we have significantly improved this reporting in case of verify errors. Would you want this to also be available when the verifications actually succeed too?

      • Take into account existing tests before removing things

        The Isuses log shows items that are going to be removed for release 3.5. While Rhino Mocks takes backwards compatibility a bit too far there is something to be said for stability in code that tests rely on. If every release or two of Moq I have to refactor a lot of tests there is no way I'm going to be able to continue using it.

        2 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          I agree to the terms of service
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          1 comment  ·  Admin →

          We’re working hard to keep backs compat, by basically hiding old/legacy API members and keeping compilation intact.

          We do remove members after 2 major versions, so you have to refactor as needed. That said, the intermediate version (the one containing the obsolete and warnings) helps you to see what you should be using instead.

          At the end of the day, if a given version of Moq does everything you need, you have no reason to upgrade to an incompatible version (which wouldn’t happen more than once a year, approx). I just pushed a couple breaking changes to 4.0 as that’s the next major release post-3.0.

          Keeping legacy APIs for 2 major versions gives you plenty of time to refactor or consider NOT to upgrade. We want to support new Moq scenarios without confusing new users with legacy APIs that are no longer in use.

          Would you prefer that we keep…

        • Expose IDefaultValueProvider?

          For example, if I want to override a loose mock to also return empty lists or a dummy object for a specific type.

          Currently, I've set up a mock factory class that will use reflection on the interface after the mock has been created. If a method returns a type that I'd like a different default value for, it uses reflection to call Setup using that method and returning the empty list / dummy object. It works, but it's really slow.

          2 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            I agree to the terms of service
            Signed in as (Sign out)
            You have left! (?) (thinking…)

            It also returns empty for enumerables and iqueryables.
            if you set the default value to DefaultValue.Mock, you’d get an empty list too. Have you tried that?

          • Don't see your idea?

          General

          Feedback and Knowledge Base