First off let's look at all the ways we can create something..
repository.CreateMock() + 2 variations. Marked as obsolete.
repository.StrictMock() + 2 variations.
repository.Stub()
MockRepository.GenerateStub<>()
repository.DynamicMock() + 2 variations
MockRepository.GenerateMock<>()
repository.PartialMock() + 1 variation
Which isn't to say that they don't all have a purpose.. but we're talking
about 12 methods that all create a stub/mock.
And then how can we use our mock?
Record/Replay Syntax with using blocks
Record/Replay with method calls
AAA syntax using Expect()
AAA syntax using AssertThat <- aka Test Spy
I love Rhino Mocks as much as the next guy but you've got to admit that the
API has gotten a bit insane. I've been here for the evolution and I've
written code that uses CreateMock in the past so I know why things can't
just get killed off. But at this point the only thing keeping me from
switching to Moq and it's clean interface for my next greenfield project is
the fact it has that whole ugly .Object thing going on.
As a presenter I find it quite difficult to actually talk about Rhino Mocks
now because there are so many ways to do things. I'm not really sure what
can be done though. I do like the fact that the latest StructureMap went
.Net 3.5 only and cleaned up their interface but I'm also not so happy that
.Net 2.0 support within StructureMap is gone but that's a completely
different story since for the most part there are very few places you need
to update your StructureMap usage (if you've wrapped it properly). Not so
much with Rhino Mocks which is sprinkled through your test code.
On Wed, Apr 1, 2009 at 7:45 AM, Tim Barcz <timba...@gmail.com> wrote:
> what areas do you see where clean up could occur? Phrased another way,
> what is crowded?
>
>
> On Wed, Apr 1, 2009 at 8:33 AM, Shane Courtrille <
> shanecourtri...@gmail.com> wrote:
>
>> Why would we want ANOTHER way to do something that is already possible?
>> The Rhino Mocks API is already getting kind of crowded...
>>
>> On Wed, Apr 1, 2009 at 7:23 AM, Koen Verheyen <verheyen.k...@gmail.com>wrote:
>>
>>>
>>> Hi Ayende,
>>>
>>> Dunno if I’m asking for a bit of support here or a feature request.
>>>
>>> What I wanna do a lot with Rhino Mocks is the following: I set an
>>> expectation on a dependency (dynamic mock) on a method that takes
>>> parameters, but I have a lot of cases where I don’t know one of the
>>> parameters (usually a reference that is created in the scope of the
>>> public method I’m testing).
>>>
>>> I found two ways of doing this, with “Constraints” and “WhenCalled”:
>>> swimlaneRepository.Expect(r => r.QuerySwimlanesToRemove(Guid.Empty,
>>> null)).Constraints(Is.Equal(processDefinitionId), Is.Anything());
>>>
>>> swimlaneRepository.Expect(r => r.QuerySwimlanesToRemove(Guid.Empty,
>>> null)).IgnoreArguments().WhenCalled(
>>> mo =>
>>> {
>>> Assert.AreEqual(processDefinitionId, mo.Arguments[0]);
>>> });
>>>
>>> … but would like to write it more or less, like this:
>>>
>>> swimlaneRepository.Expect(r => r.QuerySwimlanesToRemove
>>> (processDefinitionId, null)).IgnoreArguments(1);
>>>
>>> ... where “1” points to the second parameter and ignoring only that
>>> one, but still expecting the value of the first parameter (index 0).
>>> The argument of “IgnoreArguments” would thus be “params int[]”
>>>
>>> Is there already something like this in Rhino mocks? If not, I think
>>> it’d be a nice feature request (if technically possible)...
>>>
>>> Thanks
>>>
>>> Koen
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino.Mocks" group.
To post to this group, send email to RhinoMocks@googlegroups.com
To unsubscribe from this group, send email to
rhinomocks+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/RhinoMocks?hl=en
-~----------~----~----~----~------~----~------~--~---
