Tim how far did you get with this... I am almost done with adding Partials, MultiMock, and StrictMock.... Do we really need a strict mock anymore?
The only major issue I had was with test case for the MultiMock that was choking on the AssertExactlySingleExpectaton because calling the method collectionBase.Clear() actually calls collectionBase.OnClearing () and collectionBase.OnClearCompleted() which are protected virtual and getting caught by the RhinoInterceptor. There is no easy solution for ensuring that people are only doing a Single Expectation Assertion in foo.AssertWasCalled(...). I went down the rabbit hole of changing Action<T> to Expression<Action<T>> which does not work when trying to assert assignment from a property setter... maybe in .net 4.0 when we get full expression tree support with the DLR will it work?? For now the work around in the MultiMock test was to simply call baseCollection.VerifyAllExpectations() which seemed to do the trick. I am just doing a little cleanup at this point, should I commit when I am done or would you guys rather see a patch? Adam On Jun 28, 7:51 pm, Tim Barcz <[email protected]> wrote: > Yep, that's what I've got basically added. PartialMocks were very easy, I > will get committed to trunk...but I don't have yet is > StrictMultiMocks....those are proving more difficult. > > Tim > > > > > > On Sun, Jun 28, 2009 at 7:27 PM, Kenneth Xu <[email protected]> wrote: > > > Hi Tim, > > > After looking at the source code of Rhino.Mocks. I started using > > PartialMock for AAA in my tests. It is working surprisingly well. See > > the code below. > > > Cheers, > > Kenneth > > > class Mockery : MockRepository > > { > > public static T GeneratePartialMock<T>(params object[] > > argumentsForConstructor) > > where T : class > > { > > var mockery = new MockRepository(); > > var mock = mockery.PartialMock<T>(argumentsForConstructor); > > mockery.Replay(mock); > > return mock; > > } > > } > > > [Test] public void > > NewTaskForCallGetsNewTaskFromAbstractExecutorService() > > { > > Call<T> call = delegate > > { > > return TestData<T>.One; > > }; > > > var futureTask = > > Mockery.GeneratePartialMock<FutureTask<T>>(call); > > > ExpectExecuteCallAndRunTheRunnableInCurrentThread(); > > _executor.Expect(e => e.NewTaskFor(call)).Return(futureTask); > > > var f1 = _sut.Submit(call); > > Assert.That(f1, Is.SameAs(futureTask)); > > var f2 = _sut.Poll(); > > Assert.That(f2, Is.SameAs(futureTask), "submit and take > > must return same objects"); > > futureTask.AssertWasCalled(ft => ft.Done()); > > _executor.VerifyAllExpectations(); > > } > > > private void ExpectExecuteCallAndRunTheRunnableInCurrentThread() > > { > > _executor.Expect(e => e.Execute(Arg<IRunnable>.Is.NotNull)) > > .WhenCalled(r => ((IRunnable)r.Arguments[0]).Run()); > > } > > > On Sat, Jun 27, 2009 at 11:40 AM, Kenneth Xu<[email protected]> wrote: > > > +1. For all the developers with whom I have worked, including myself, > > > it took us a while to get used to record/reply. Then end up with > > > overly interactive test cases that fails whenever the implementation > > > changes. Only a few good ones eventually start to think when to stub > > > and when to mock and what to expect, but it took even longer than the > > > time taken understanding record/replay. > > -- > Tim Barcz > ASPInsiderhttp://timbarcz.devlicio.ushttp://www.twitter.com/timbarcz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/RhinoMocks?hl=en -~----------~----~----~----~------~----~------~--~---
