As I commented on the blog, it might be a good idea to let the user choose whether he want to have the properties of his mocks filled or not. Why? Because at least for Rhino Mocks and Moq it makes a difference, as they support auto property behavior or null behavior (values assigned to properties are lost, properties always return default(T))

That would be nice. For example, in order to mock an IController interface and fill the User property one needs to create mocks for IPrincipal, HttpContextBase and ControllerContext then assign the User to HttpContextBase, assign that to ControllerContext and finally assign to mocked controller instance.

This overall process will by done automatically, I think, when this feature is implemented. So this would be a very nice extension.

Please have a look at the AutoNSubstitute fork. In this I implemented the auto-filling functionality for mocks created with NSubstitute. Does it behave the way you expected?

While I agree that this would make it easier to work with HttpContextBase and its ilk, keep in mind that this basically demonstrates how crappy an API the web abstractions actually are ;)

...Indeed :)

My group has adopted the practice of exposing only interfaces as return objects and parameters for our business-layer API. This is a fairly new change so it's possible that we'll eventually come to understand why Mark considers interface properties to be a code smell. However, for the time being, this has allotted the following benefits for our MVC application: (1) ViewModel objects can implement parameter interfaces which prevents the need to convert from the vm to the service model and (2) views models tend to be composed of one or more interfaces rather than deriving, exposing, or duplicating the properties of the service model.

So far, the two areas where this practice has been difficult are the lack of support for interface parameters in the MVC WebAPI actions and this inability to create anonymous mocks for testing. If this feature is indeed not desired by the AutoFixture team, perhaps someone from the team could give some further clues as to how to extend this functionality ourselves.

Thanks for the awesome AutoFixture libraries!

FWIW, I've posted a couple of blog posts describing how to achieve this effect: http://blog.ploeh.dk/2013/04/08/how-to-automatically-populate-properties-with-automoq/