I could not find any information on the site or the readme.txt/changelog.txt files listing what's new in the upcoming 4.0 version of Moq. A little preview would be awesome

"NuPack is a package management system for .NET. The goal of NuPack is to make the process of incorporating third party libraries into your solutions as simple as possible."

http://nupack.codeplex.com/documentation?title=Creating%20a%20Package

The quickstart page is a great reference for those occasions when the natural syntax doesn't tell you what you need.

But it's missing examples on how to setup callbacks when ref and out parameters are used, and everytime I come across one of these situations I've forgotten what the rules are.

Adding them to quickstart would be very helpful.

I just started using Moq and all of the examples (including the one on the home page) uses obsolete methods. It's fairly easy to find the reference to the new methods by using Intellisense but if the API documentation link worked it would be great to find examples.

It would be nice if protected setups could be verified using Times (Never, Once, etc.) just like normal setups.

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.

It is understood, that you are under limitations of DynamicProxy library, but it really limit applicability of Moq, a lot.

It would be nice, if Moq use someting capable to create proxies which would allow you to intercept all calls (i.e. not derive a class).

Probably Unity may help here (at least, when it instrument a class, there is no limitations like for Castle DynamicProxy).

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());

http://code.google.com/p/moq/source/browse/trunk/Changelog.txt is outdated, whats new in 4.0?

I implemented my own DynamicProxy and would like to put my implementation underneath the Mock<> facade.

I kept hearing the Moq should support VB10, but I I'm having dificulty converting over C# samples to VB10, not sure if it's my code or if there are still VB10 compatibility issues? Some VB10 Quickstart exmamples would be great if VB10 is now supported?

a thought. the need for auto-mocking hierarchies (recursive mocks) is a smell that LoD has been violated.

is good to support auto-mocking hierarchies then ?

Raise() doesn't raise an event on a recursively-mocked interface (i.e. the event belongs to the interface of a recursively-mocked property).

I had a Unit Test with following attribute: [ExpectedException(typeof(ArgumentException))]
So the test would succeed when this exception was thrown.

But because I was incorrectly using Moq, my test would always pass. During the Setup() method, Moq was throwing an ArgumentException. Now if incorrect usage (fex using a sealed class to mock, or a property that's not defined as virtual) would throw MoqException, the test would fail, causing me to search for the problem.

mock.Verify(m => m.Do(), Times.Once);

The errormessage says the method was invoked more than once, even though the method was never invoked.

This will allow to write tests like the following, which AFAICT are not possible at the moment:

// Arrange:
var mock = new Mock<IFoo>();
// Automatically return defaults for everything, so no additional setup.

// Act:
...

// Assert:
mock.Verify(foo => foo.SomeMethod());
mock.Verify(foo => foo.AnotherMethod());
mock.VerifyNoMoreInteractions();

Of course, one could use strict mode and specify all the expectations in advance, but that somewhat breaks the AAA approach.

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.

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.