Thanks!

You would use your container to resolve the service dependency transitively? I guess why not if you use the AMC…

The key is liberal usage of SetupResult.For() and LastCall.PropertyBehavior(). Just be sure to Expect.Call() anything you actually want to be called (and verify it). The benefit is that you can simplify the way your tests look… you just always construct the subject under test with the same dynamic mocks (or that happens automatically w/ AMC) rather than declaring stubs and substituting mocks when you need to.

Dynamic”Mocks” are “stubs” until you tell them not to be… for the most intents and purposes.

I mean… isn’t this nicer:
private MockRepository _mocks;
private AutoMockingContainer _container;
private SearchPresenter _presenter;
private SearchResultDTO _fakeResults;

[SetUp]
public void Setup()
{
this._mocks = new MockRepository();
this._container = new AutoMockingContainer(_mocks);
this._presenter = _container.Create();
this._fakeResults = new SearchResultDTO();
}

[Test]
public void Can_search_for_customers_by_number_of_orders()
{
using (_mocks.Record())
{
Expect
.Call(_container.Get().GetCustomersByOrderCount(42))
.Return(this._fakeResults);
}

using (_mocks.Playback())
{
_presenter.SearchByOrderCount(42);
}
}

[Test]
public void Search_results_are_displayed_to_the_user()
{
using (_mocks.Record())
{
mockView.SearchResults = _fakeResults;
SetupResult
.For(_container.Get().GetCustomersByOrderCount(42))
.Return(_fakeResults);
}

using (_mocks.Playback())
{
presenter.SearchByOrderCount(42);
}
}