Ayende @ Rahien

Morten Lyhr commented on Rhino Mocks - Arrange, Act, Assert Syntax

Wed, 09 Jul 2008 06:54:28 GMT

I really like it alot. I have written about BDD and AAA syntax here: http://morten.lyhr.dk/2008/07/doing-bdd-with-rhino-mocks-aaa-syntax.html They really mix very well.

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Wed, 25 Jun 2008 11:58:20 GMT

This should go to the mailing list

Michael Reichenauer commented on Rhino Mocks - Arrange, Act, Assert Syntax

Wed, 25 Jun 2008 07:51:02 GMT

Hi! Thanks for the new 3.5 beta syntax, it is really nice to use. However I have problems with mocking properties. E.g.: var httpClient = MockRepository.GenerateStub(); httpClient.BaseAddress = "blah"; httpClient.AssertWasCalled(x => x.BaseAddress = "blah"); Will cause a ExpectationViolationException on the third row. And also trying to mock properties properties with: var httpClient = MockRepository.GenerateStub(); httpClient.Stub(m => m.BaseAddress).Return("mocked"); or: httpClient.Stub(m => m.BaseAddress = null).Throw(new ArgumentException("error")); fails on the Stub rows with a "InvalidOperationException : Invalid call, the last call has been used or no call has been made ..." I would appreciate if someone could give me a hint.

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Sat, 14 Jun 2008 01:46:23 GMT

Yes, I'll try to do that.

Jeremy Gray commented on Rhino Mocks - Arrange, Act, Assert Syntax

Sat, 14 Jun 2008 01:36:00 GMT

Yes, Ayende, I understand that the objects can be used without explicit record/replay, and have been using them that way quite successfully for most of the week. What I am curious about, though, is that the two methods are returning objects that don't seem to align with the previous terminology. The Mocks, for example, can be used as partial mocks, and more importantly have changed their strictness (they are acting much more loose than those returned from the classic StrictMock calls). I understand that you have yet to document this new syntax fully, but could you at least post a quick list of old call versus new call so that we can know what is what?

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Sat, 14 Jun 2008 00:52:33 GMT

The static methods are returning an object that can be used without record/replay. It is already in replay mode, which is needed to use the AAA syntax. The missing partial is mainly an issue with not adding it, not a design decision. I need to document that part fairly heavily

Jeremy Gray commented on Rhino Mocks - Arrange, Act, Assert Syntax

Tue, 10 Jun 2008 17:22:13 GMT

Hehe. Nice copy/paste editing error on my part in that last comment. The actual question from me to Ayende should read: Could you perhaps post back a quick reply comment showing what maps to what between the old MockRepository instance methods and the new static GenerateMock and GenerateStub methods?

Jeremy Gray commented on Rhino Mocks - Arrange, Act, Assert Syntax

Tue, 10 Jun 2008 17:17:52 GMT

@Ayende - I know this is now an old-ish post but thought it the best place to pose this question: I've been trying out the AAA syntax in the last day and noticed that GenerateMock doesn't appear to produce strict mocks, nor can it take constructor arguments. On the other hand, instances returned from GenerateStub seem capable of taking on expectations, which given the now-looser semantics of GenerateMock would tempt me to suggest that the only difference between GenerateMock and GenerateStub should be that instances returned by GenerateStub shouldn't be able to take on any expectations. I've also noticed that there is no Generate* equivalent to PartialMock, though both GenerateStub and GenerateMock seem happy to produce one (not that I can tell the difference in expected behaviour due to the other things noted earlier.) Could you perhaps post back a quick reply comment showing what maps to what between the between old the MockRepository instance methods and the new static GenerateMock and Generatestub methods? Thanks in advance!

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 26 May 2008 21:34:04 GMT

Stub() doesn't set an expectation. However, what I have found is that very often you want to do things like: userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" }) userRepository.Stub(x => x.GetUserById(6)).Return(new User { Id = 6, Name = "brad" }) This is just matching to parameters. You can ask to not do that, but it turn out to be a rarer case in most scenarios.

Brad Wilson commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 26 May 2008 19:23:54 GMT

I don't particularly like this: userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" }) Because it mixes together what could be considered an assertion (I expect them to ask for user ID 5) with the stubbing behavior (return this). As an alternative, I think I'd prefer: userRepository.StubReturn(x => x.GetUserById, new User { Id = 5, Name = "ayende" }) And then add an assertion about things being called correctly to the bottom: userRepository.AssertWasCalled(x => x.GetuserById(5))

Onur Gumus commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 26 May 2008 12:58:30 GMT

After some thought here is my implementation: var mocks = new MockRepository(); var view = MockRepository.GenerateMock(); var provider = MockRepository.GenerateStub(); var result = new List(); result.Add(new BaseFinanceData(){ Sell=1.1M, Buy = 2.2M}); view.Expect(v => v.CBOTExchangeRates).PropertyBehavior(); var loadRaiser = view.Expect(v => v.CBOTExchangeRatesRequested += null).IgnoreArguments().GetEventRaiser(); provider.Stub(p => p.GetCBOTExchangeRates()).Return(result); var presenter = new SmartInvest.Presenter.CBOTExchangeRatePresenter(); presenter.View = view; presenter.ExchangeProvider = provider; loadRaiser.Raise(view, EventArgs.Empty); view.VerifyAllExpectations(); Assert.AreEqual(1, view.CBOTExchangeRates.Count);

Onur Gumus commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 26 May 2008 12:28:36 GMT

How do I test events with this syntax. My old test case is as below (appliying Model View Presenter) Can you please guide me a little bit : var mocks = new MockRepository(); var view = mocks.DynamicMock(); var provider = mocks.DynamicMock(); SetupResult.For(view.CBOTExchangeRates).PropertyBehavior(); var result = new List(); result.Add(new BaseFinanceData(){ Sell=1.1M, Buy = 2.2M}); view.CBOTExchangeRatesRequested += null; var loadRaiser = LastCall.IgnoreArguments().GetEventRaiser(); Expect.Call(provider.GetCBOTExchangeRates()).Return(result); mocks.ReplayAll(); var presenter = new CBOTExchangeRatePresenter(); presenter.View = view; presenter.ExchangeProvider = provider; loadRaiser.Raise(view, EventArgs.Empty); Assert.AreEqual(1, view.CBOTExchangeRates.Count);

Stanislav Dvoychenko commented on Rhino Mocks - Arrange, Act, Assert Syntax

Thu, 22 May 2008 19:22:03 GMT

Do with Action would be nice to have, I'm trying the Beta but see only IMethodOptions Do(Delegate action); which can't convert from lambda expression (and from anonymous delegate as well I guess?). God, it will be great to have lambda expressions everwhere.

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Thu, 22 May 2008 10:38:45 GMT

mock.AssertWasCalled(x => x.Name = "blah");

Carel Lotz commented on Rhino Mocks - Arrange, Act, Assert Syntax

Thu, 22 May 2008 07:46:30 GMT

Is it possible to assert that a property setter was called using the new syntax?

Neil Mosafi commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 19 May 2008 21:51:57 GMT

Great syntax, I love it!

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 19 May 2008 21:03:32 GMT

Depends on what you are trying to achieve. This would return the same instance for all calls. This is probably what you are trying to get: factory.Stub((f) =>f.CreateParameter()).Repeat.Any.Do( () => MockRepository.GenerateStub());

Stanislav Dvoychenko commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 19 May 2008 20:59:49 GMT

Will it be possible to have something like: factory.StubAny((f) => f.CreateParameter()).Return(MockRepository.GenerateStub()); The intent here would be to Stub Any call with this Return. Right now it looks like it is required to call Stub as many times as code under test will call it ...

Jimmy Bogard commented on Rhino Mocks - Arrange, Act, Assert Syntax

Mon, 19 May 2008 16:31:15 GMT

I think this constraint syntax is finally viable. It always bothered me to have my constraints mixed in with my setup code. I want my assertions to be as clear as possible. Looking good...though the name "GenerateStub" seems strange to me. Here's hoping we all simultaneously and spontaneously adapt Meszaros' test double nomenclature.

Ayende Rahien commented on Rhino Mocks - Arrange, Act, Assert Syntax

Sat, 17 May 2008 16:11:24 GMT

John, Yes, we are going to remain backward compatible with the previous versions.

John Chapman commented on Rhino Mocks - Arrange, Act, Assert Syntax

Sat, 17 May 2008 14:48:45 GMT

Ayende, Awesome work. The AssertWasCalled looks to be a godsend for me. I've always wanted a way to verify just a single expectation at a time on a given mock. It would allow me to use a single set up and then many tests with only a single expectation check, versus when there are are two expectations on a mock and now you need to verify both on the mock. If there is another way now I would love to hear about it, for now I just look forward to your next release. Good work! For clarification, will both syntax options be available in the new release? The above syntax as well as the old legacy syntax, or will everything need to move over? I could see that causing some real issues for me as our project has a significant number of tests making sue of Rhino Mocks already.

Jeremy Gray commented on Rhino Mocks - Arrange, Act, Assert Syntax

Fri, 16 May 2008 14:13:25 GMT

When it comes to more advanced argument validation I find myself waffling back and forth between the pros and cons of the WithConstraints and WithArgMatchingInTheLambda options so it is nice to see that both options will (?) be available. Everything else is looking very nice, as much as I still have yet to be convinced of the merit of act/arrange/assert over the classic set-expectations/exercise/assert(&verify) style, except perhaps for the simplicity of the very phrase "act/arrange/assert". :)