Good point..
Ayende some clarification would be good. Did you mean assert the results
from the SUT (state based) OR AssertWasCalled on the Stub (interaction
based) ?
On Fri, Nov 7, 2008 at 8:00 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
> I think you have to take care when you say "assert on the results". I'm
> pretty certain you mean state based, but with the new extension methods, it
> does get blurry, especially when you can do stubObject.AssertWasCalled.
>
>
>
> On Fri, Nov 7, 2008 at 8:57 AM, Ayende Rahien <[EMAIL PROTECTED]> wrote:
>
>> Shane,I think that a good guidance would be to tell anyone who doesn't
>> really care about the difference to just use stubs, and assert on the
>> results.
>> And then we can direct them to Single assert per test rule.
>>
>>
>> On Fri, Nov 7, 2008 at 4:54 PM, Shane Courtrille <
>> [EMAIL PROTECTED]> wrote:
>>
>>> I was originally responding to Ayende.. then I realized my original
>>> response didn't clarify what I was saying No about.
>>>
>>> The difference for me is in interaction based testing.
>>>
>>> The only place I use a mock is when I need to verify behavior but the
>>> only way to do that is to verify that interaction occured with another class
>>> (aka Interaction based testing). For me the canonical example is a class
>>> calling a Repository (data access provider) to save something. In a unit
>>> test I don't want to call the live Repository since that would access the
>>> live database. BUT it's very important that I verify that the save occurs.
>>> In this instance I would create a SINGLE test that uses a mock to verify
>>> this one interaction.
>>>
>>> Now instead let's say I have a Foo that calls IBar for a piece of
>>> information and without that information the class blows up (the result
>>> can't be null for instance). Now this may be a case where I care about the
>>> interaction in which case again I create a SINGLE test that uses a mock.
>>> BUT for every other test I would use a Stub to provide the value that Foo
>>> requires to do it's job.
>>>
>>> This I believe is keeping inline with the single assertion principle
>>> (which I'm sure has a real name I'm forgetting). In my world I use a mock
>>> to create an assertion and a stub to provide information a class requires to
>>> do it's job.
>>>
>>> Hopefully that clears up my beliefs a little bit..?
>>>
>>>
>>>
>>> On Fri, Nov 7, 2008 at 7:44 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>>>
>>>> Shane,
>>>>
>>>> Not following who you were replying to...can you clarify?
>>>>
>>>> Also, summarize your stance on Mocks vs. Stubs.
>>>>
>>>> I *can* assert interaction with a stub, see the test case that was
>>>> provided in the first post.
>>>>
>>>>
>>>> On Fri, Nov 7, 2008 at 8:42 AM, Shane Courtrille <
>>>> [EMAIL PROTECTED]> wrote:
>>>>
>>>>> This email should have said "No.. you are correct that there is not
>>>>> really that much of a difference"
>>>>>
>>>>>
>>>>> On Fri, Nov 7, 2008 at 7:42 AM, Shane Courtrille <
>>>>> [EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> No.. and that is the problem. The difference is very much a
>>>>>> conceptual thing so it's very important that it be protected. By
>>>>>> allowing
>>>>>> the assertion of stub calls the usage of stub and mock is diluted.
>>>>>>
>>>>>> Maybe you can help us understand why someone want to be able to assert
>>>>>> stub calls and your view on why this was a good feature to add? Isn't
>>>>>> that
>>>>>> what a mock is for?
>>>>>>
>>>>>> Shane
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 7, 2008 at 7:08 AM, Ayende Rahien <[EMAIL PROTECTED]>wrote:
>>>>>>
>>>>>>> Because there isn't really much of a difference between the two, and
>>>>>>> I got feature request to be able to assert of stub calls.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 7, 2008 at 4:03 PM, Shane Courtrille <
>>>>>>> [EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>>> Which to me is the standard difference between the two.
>>>>>>>>
>>>>>>>> The question is why does the interface for a stub have to support
>>>>>>>> operations which are the domain of a mock object? When a new comer
>>>>>>>> looks at
>>>>>>>> a Stub shouldn't they be able to tell the difference without having to
>>>>>>>> deal
>>>>>>>> with the mental baggage of "Hey wait.. a stub looks a lot like a mock
>>>>>>>> to
>>>>>>>> me".
>>>>>>>>
>>>>>>>> Shane
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Nov 7, 2008 at 6:15 AM, Ayende Rahien <[EMAIL PROTECTED]>wrote:
>>>>>>>>
>>>>>>>>> The main thing is a concpetual difference.I would use stub if I
>>>>>>>>> don't care about what is going to happen
>>>>>>>>> I would use a mock if I do care.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Nov 7, 2008 at 2:05 PM, Tim Barcz <[EMAIL PROTECTED]>wrote:
>>>>>>>>>
>>>>>>>>>> I am working on a presentation and was about to make the
>>>>>>>>>> assertion, "stubs can't have expectations set on them". I decide to
>>>>>>>>>> double
>>>>>>>>>> check myself and run the following code and see that I can set
>>>>>>>>>> expectations. (Removing the call to logger.Log in the Order method
>>>>>>>>>> causes
>>>>>>>>>> the test to fail).
>>>>>>>>>>
>>>>>>>>>> [TestFixture]
>>>>>>>>>> public class Stubs
>>>>>>>>>> {
>>>>>>>>>> [Test]
>>>>>>>>>> public void CreateStub()
>>>>>>>>>> {
>>>>>>>>>> var logger = MockRepository.GenerateStub<ILogger>();
>>>>>>>>>>
>>>>>>>>>> var svc = new OrderService(logger);
>>>>>>>>>>
>>>>>>>>>> svc.Order();
>>>>>>>>>>
>>>>>>>>>> logger.AssertWasCalled(x=>x.Log("hello"));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public class OrderService
>>>>>>>>>> {
>>>>>>>>>> private readonly ILogger logger;
>>>>>>>>>>
>>>>>>>>>> public OrderService(ILogger logger)
>>>>>>>>>> {
>>>>>>>>>> this.logger = logger;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public void Order()
>>>>>>>>>> {
>>>>>>>>>> logger.Log("hello");
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public interface ILogger
>>>>>>>>>> {
>>>>>>>>>> void Log(string message);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
