Would love to know this as well. It's kind of annoying. On Tue, Jul 7, 2009 at 8:19 AM, Adam Tybor <[email protected]> wrote:
> > I commited some stuff yesterday in trunk that i would like to be > reviewed. i am not crazy about all the generatxxx methods. I really > like the fluent Type marker pattern that is in rhino.testing. > > Also why r partials strict mocks? > > Adam > Tim Barcz wrote: > > I say we bring forward strict mock....looking for feature parity with > > Record/Replay so it can go away. > > > > Tim > > > > On Mon, Jul 6, 2009 at 9:11 AM, Adam Tybor <[email protected]> wrote: > > > > > > > > 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 > > > > > > > > > > > > > -- > > Tim Barcz > > ASPInsider > > http://timbarcz.devlicio.us > > http://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 -~----------~----~----~----~------~----~------~--~---
