[RhinoMocks] Re: Mocks Vs Stubs Am I doing it right?????

[Tim Barcz]

That link should provide enough to answer this question:

Should I be using the view as a stub and doing state based assertions
> as I have done. The reason I am doing this is because I want to make
> sure when I find the entity and update the view the values in the view
> should be the same as the entity or should i use a dynamic mock and
> set expectation on the view being called?




On Mon, Dec 8, 2008 at 1:39 AM, Blair <[EMAIL PROTECTED]> wrote:

>
> I found the link content not that useful. Any other info on this
>
> On Dec 8, 12:54 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > Here's the testing methodology I currently ascribe to...
> >
> >- Favor state based testing
> >- Test interactions only on void (ie. one-way calls)
> >
> > (this is not my own idea, but rather adapted from this blog post by Roy
> > Osherovet:
> http://weblogs.asp.net/rosherove/archive/2008/09/20/goodbye-mocks-far...
> > )
> >
> > I think the above, when understood, provides the answer to the question
> > asked in your email.
> >
> > Happy testing,
> >
> > Tim
> >
> >
> >
> > On Sun, Dec 7, 2008 at 9:33 PM, Blair <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hi,
> >
> > >I am using the MVP design for a website I am developing at the
> > > moment. I am hoping that I am using the Mocking framework correctly.
> >
> > > Here is a test I wrote.
> >
> > > [Test]
> > >public void ProjectPresenter_LoadProject_ShouldLoadAProject()
> > >{
> >
> > >//Create mock objects
> > >MockRepository mockRepository = new MockRepository();
> > >IProjectView view = mockRepository.Stub();
> > >IProjectService service =
> > > mockRepository.StrictMock();
> > >IRedirector redirector =
> > > mockRepository.StrictMock();
> >
> > >//Initial SUT
> > >ProjectPresenter presenter = new ProjectPresenter(view,
> > > service, redirector);
> >
> > >//Setup Stub
> > >Guid viewIdentity = Guid.NewGuid();
> > >SetupResult.For(view.Identity).Return(viewIdentity);
> > >view.Mode = DisplayMode.Edit;
> >
> > >//Setup other objects used in test case
> > >Guid id = Guid.NewGuid();
> > >PrefetchPath2 prefetchPath = new PrefetchPath2((int)
> > > EntityType.ProjectEntity)
> > > {
> >
> > > ProjectEntity.PrefetchPathContact,
> >
> > > ProjectEntity.PrefetchPathProjectPaybackPeriod,
> >
> > > ProjectEntity.PrefetchPathProjectCategory
> > > };
> >
> > >ProjectEntity entity = new ProjectEntity
> > >{
> > >Id = id,
> > >Name = "Test Project",
> > >InitiatedBy = "Blair Davidson",
> > >ProjectNumber = "PRJ001",
> > >StartDate = new DateTime(2008, 12, 5),
> > >EndDate = new DateTime(2008, 12, 20),
> > >ProjectedSavingUnitYr = 100,
> > >ProjectedSavingDollarYr = 1000,
> > >Notes = "Test Notes"
> >
> > >};
> >
> > >//Set expectations
> > >Expect.Call(service.FindByIdentity(viewIdentity,
> > > prefetchPath)).Return(entity);
> >
> > >//Move into replay mode
> > >mockRepository.ReplayAll();
> >
> > >//Call SUT
> > >presenter.LoadProject();
> >
> > >//Additional assertions
> > >Assert.AreEqual(entity.ProjectNumber, view.ProjectNumber);
> > >Assert.AreEqual(entity.Name, view.ProjectName);
> > >Assert.AreEqual(entity.InitiatedBy, view.InitiatedBy);
> > >Assert.AreEqual(entity.StartDate, view.StartDate);
> > >Assert.AreEqual(entity.EndDate, view.EndDate);
> > >Assert.AreEqual(entity.ProjectedSavingUnitYr,
> > > view.ProjectedSavingsUnitYear);
> > >Assert.AreEqual(entity.ProjectedSavingDollarYr,
> > > view.ProjectedSavingsDollarYear);
> > >Assert.AreEqual(entity.ActualSavingsUnitYr,
> > > view.ActualSavingsUnitYear);
> > >Assert.AreEqual(entity.ActualSavingsDollarYr,
> > > view.ActualSavingsDollarYear);
> > >Assert.AreEqual(entity.Notes, view.Notes);
> > >Assert.AreEqual(entity.Version, view.Version);
> >
> > >//Verify expectations
> > >mockRepository.VerifyAll();
> > >}
> >
> > > Should I be using the view as a stub and doing state based assertions
> > > as I have done. The reason I am doing this is because I want to make
> > > sure when I find the entity and update the view the values in the view
> > > should be the same as the entity or should i use a dynamic mock and
> > > set expectation on the view being called?
> >
> > > Kind Regards,
> >
> > > Blair Davidson- Hide quoted text -
> >
> > - Show quoted text -
> >
>

--~--~-~--~~~---~--~~
You received this message bec

[RhinoMocks] Re: Mocks Vs Stubs Am I doing it right?????

[Blair]

I found the link content not that useful. Any other info on this

On Dec 8, 12:54 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> Here's the testing methodology I currently ascribe to...
>
>    - Favor state based testing
>    - Test interactions only on void (ie. one-way calls)
>
> (this is not my own idea, but rather adapted from this blog post by Roy
> Osherovet:http://weblogs.asp.net/rosherove/archive/2008/09/20/goodbye-mocks-far...
> )
>
> I think the above, when understood, provides the answer to the question
> asked in your email.
>
> Happy testing,
>
> Tim
>
>
>
> On Sun, Dec 7, 2008 at 9:33 PM, Blair <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> >    I am using the MVP design for a website I am developing at the
> > moment. I am hoping that I am using the Mocking framework correctly.
>
> > Here is a test I wrote.
>
> > [Test]
> >        public void ProjectPresenter_LoadProject_ShouldLoadAProject()
> >        {
>
> >            //Create mock objects
> >            MockRepository mockRepository = new MockRepository();
> >            IProjectView view = mockRepository.Stub();
> >            IProjectService service =
> > mockRepository.StrictMock();
> >            IRedirector redirector =
> > mockRepository.StrictMock();
>
> >            //Initial SUT
> >            ProjectPresenter presenter = new ProjectPresenter(view,
> > service, redirector);
>
> >            //Setup Stub
> >            Guid viewIdentity = Guid.NewGuid();
> >            SetupResult.For(view.Identity).Return(viewIdentity);
> >            view.Mode = DisplayMode.Edit;
>
> >            //Setup other objects used in test case
> >            Guid id = Guid.NewGuid();
> >            PrefetchPath2 prefetchPath = new PrefetchPath2((int)
> > EntityType.ProjectEntity)
> >                                             {
>
> > ProjectEntity.PrefetchPathContact,
>
> > ProjectEntity.PrefetchPathProjectPaybackPeriod,
>
> > ProjectEntity.PrefetchPathProjectCategory
> >                                             };
>
> >            ProjectEntity entity = new ProjectEntity
> >            {
> >                Id = id,
> >                Name = "Test Project",
> >                InitiatedBy = "Blair Davidson",
> >                ProjectNumber = "PRJ001",
> >                StartDate = new DateTime(2008, 12, 5),
> >                EndDate = new DateTime(2008, 12, 20),
> >                ProjectedSavingUnitYr = 100,
> >                ProjectedSavingDollarYr = 1000,
> >                Notes = "Test Notes"
>
> >            };
>
> >            //Set expectations
> >            Expect.Call(service.FindByIdentity(viewIdentity,
> > prefetchPath)).Return(entity);
>
> >            //Move into replay mode
> >            mockRepository.ReplayAll();
>
> >            //Call SUT
> >            presenter.LoadProject();
>
> >            //Additional assertions
> >            Assert.AreEqual(entity.ProjectNumber, view.ProjectNumber);
> >            Assert.AreEqual(entity.Name, view.ProjectName);
> >            Assert.AreEqual(entity.InitiatedBy, view.InitiatedBy);
> >            Assert.AreEqual(entity.StartDate, view.StartDate);
> >            Assert.AreEqual(entity.EndDate, view.EndDate);
> >            Assert.AreEqual(entity.ProjectedSavingUnitYr,
> > view.ProjectedSavingsUnitYear);
> >            Assert.AreEqual(entity.ProjectedSavingDollarYr,
> > view.ProjectedSavingsDollarYear);
> >            Assert.AreEqual(entity.ActualSavingsUnitYr,
> > view.ActualSavingsUnitYear);
> >            Assert.AreEqual(entity.ActualSavingsDollarYr,
> > view.ActualSavingsDollarYear);
> >            Assert.AreEqual(entity.Notes, view.Notes);
> >            Assert.AreEqual(entity.Version, view.Version);
>
> >            //Verify expectations
> >            mockRepository.VerifyAll();
> >        }
>
> > Should I be using the view as a stub and doing state based assertions
> > as I have done. The reason I am doing this is because I want to make
> > sure when I find the entity and update the view the values in the view
> > should be the same as the entity or should i use a dynamic mock and
> > set expectation on the view being called?
>
> > Kind Regards,
>
> > Blair Davidson- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks Vs Stubs Am I doing it right?????

[Tim Barcz]

Here's the testing methodology I currently ascribe to...

   - Favor state based testing
   - Test interactions only on void (ie. one-way calls)

(this is not my own idea, but rather adapted from this blog post by Roy
Osherovet:
http://weblogs.asp.net/rosherove/archive/2008/09/20/goodbye-mocks-farewell-stubs.aspx
)

I think the above, when understood, provides the answer to the question
asked in your email.

Happy testing,

Tim

On Sun, Dec 7, 2008 at 9:33 PM, Blair <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
>I am using the MVP design for a website I am developing at the
> moment. I am hoping that I am using the Mocking framework correctly.
>
> Here is a test I wrote.
>
> [Test]
>public void ProjectPresenter_LoadProject_ShouldLoadAProject()
>{
>
>//Create mock objects
>MockRepository mockRepository = new MockRepository();
>IProjectView view = mockRepository.Stub();
>IProjectService service =
> mockRepository.StrictMock();
>IRedirector redirector =
> mockRepository.StrictMock();
>
>//Initial SUT
>ProjectPresenter presenter = new ProjectPresenter(view,
> service, redirector);
>
>//Setup Stub
>Guid viewIdentity = Guid.NewGuid();
>SetupResult.For(view.Identity).Return(viewIdentity);
>view.Mode = DisplayMode.Edit;
>
>//Setup other objects used in test case
>Guid id = Guid.NewGuid();
>PrefetchPath2 prefetchPath = new PrefetchPath2((int)
> EntityType.ProjectEntity)
> {
>
> ProjectEntity.PrefetchPathContact,
>
> ProjectEntity.PrefetchPathProjectPaybackPeriod,
>
> ProjectEntity.PrefetchPathProjectCategory
> };
>
>
>ProjectEntity entity = new ProjectEntity
>{
>Id = id,
>Name = "Test Project",
>InitiatedBy = "Blair Davidson",
>ProjectNumber = "PRJ001",
>StartDate = new DateTime(2008, 12, 5),
>EndDate = new DateTime(2008, 12, 20),
>ProjectedSavingUnitYr = 100,
>ProjectedSavingDollarYr = 1000,
>Notes = "Test Notes"
>
>};
>
>//Set expectations
>Expect.Call(service.FindByIdentity(viewIdentity,
> prefetchPath)).Return(entity);
>
>//Move into replay mode
>mockRepository.ReplayAll();
>
>//Call SUT
>presenter.LoadProject();
>
>//Additional assertions
>Assert.AreEqual(entity.ProjectNumber, view.ProjectNumber);
>Assert.AreEqual(entity.Name, view.ProjectName);
>Assert.AreEqual(entity.InitiatedBy, view.InitiatedBy);
>Assert.AreEqual(entity.StartDate, view.StartDate);
>Assert.AreEqual(entity.EndDate, view.EndDate);
>Assert.AreEqual(entity.ProjectedSavingUnitYr,
> view.ProjectedSavingsUnitYear);
>Assert.AreEqual(entity.ProjectedSavingDollarYr,
> view.ProjectedSavingsDollarYear);
>Assert.AreEqual(entity.ActualSavingsUnitYr,
> view.ActualSavingsUnitYear);
>Assert.AreEqual(entity.ActualSavingsDollarYr,
> view.ActualSavingsDollarYear);
>Assert.AreEqual(entity.Notes, view.Notes);
>Assert.AreEqual(entity.Version, view.Version);
>
>//Verify expectations
>mockRepository.VerifyAll();
>}
>
> Should I be using the view as a stub and doing state based assertions
> as I have done. The reason I am doing this is because I want to make
> sure when I find the entity and update the view the values in the view
> should be the same as the entity or should i use a dynamic mock and
> set expectation on the view being called?
>
> Kind Regards,
>
> Blair Davidson
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[ssteinegger]

I love to confuse you again with this pretty piece of code from the
documentation
(http://ayende.com/Wiki/Rhino+Mocks+3.5.ashx)

public void When_user_forgot_password_should_reset_password()
{
var stubUserRepository =
MockRepository.GenerateStub();

// ...

stubUserRepository.AssertWasCalled( x => x.Save(user));
}

And I have to say, I like it. I wouldn't do it all in the same test
method. But, I repeat myself, we have a test framework that sets up
test doubles. This could all be stubs, the framework does not have to
know if a single test wants it to be a stub or a mock. The test can
assert for calls, making it a mock, or not and it keeps being a stub.
You can argue that the name is wrong and should be
GenerateTestDouble() or something. But I don't care about that.



On 11 Nov., 14:54, boo <[EMAIL PROTECTED]> wrote:
> The book 'the Art of Unit Testing' is worth every penny to help people
> who are young in unit testing get started (if you can get around the
> typos).  The author has a great way of explaining the diff's between
> mocks and stubs, it is also an excellent read for those who already
> know something about testing, or TDD in general, as they may find
> there is something they didn't think about.  95% of the example in the
> book that use a mocking framework use RhinoMocks, and that alone
> helped me to learn more about RhinoMocks than anything on the
> RhinoMocks site.
>
> To summarize from the book:
>
> 1.  Stubs just make happy noises for your test to pass.  They serve no
> other purpose than that.   You *never* test against a stub.
> 2.  Mocks are used for testing production code.  If you can't test
> against the real object, or it's cumbersome to test against the real
> object, you test against a mock.
> 3.  Use mocks and stubs only where you have to.   Just because you
> can, doesn't mean you should.
> 4   Only one mock per test.  If you have to use more than one mock you
> are either trying to test too much (test is testing more than a single
> function).  It could also be a sign that your method is attempting to
> do too much also, or a combination of the too.
> 5.  If you are truly only testing one thing in your tests, which you
> should be, the usuage of mocks and stubs fall in place if follow
> numbers 1-4.
>
> I whole heartidly believe you would be doing your group a disservice
> by not helping them to understand the difference between a stub and
> mock and you would probably hinder there ability to effectively use a
> mocking framework or write good tests.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[boo]

The book 'the Art of Unit Testing' is worth every penny to help people
who are young in unit testing get started (if you can get around the
typos).  The author has a great way of explaining the diff's between
mocks and stubs, it is also an excellent read for those who already
know something about testing, or TDD in general, as they may find
there is something they didn't think about.  95% of the example in the
book that use a mocking framework use RhinoMocks, and that alone
helped me to learn more about RhinoMocks than anything on the
RhinoMocks site.

To summarize from the book:

1.  Stubs just make happy noises for your test to pass.  They serve no
other purpose than that.   You *never* test against a stub.
2.  Mocks are used for testing production code.  If you can't test
against the real object, or it's cumbersome to test against the real
object, you test against a mock.
3.  Use mocks and stubs only where you have to.   Just because you
can, doesn't mean you should.
4   Only one mock per test.  If you have to use more than one mock you
are either trying to test too much (test is testing more than a single
function).  It could also be a sign that your method is attempting to
do too much also, or a combination of the too.
5.  If you are truly only testing one thing in your tests, which you
should be, the usuage of mocks and stubs fall in place if follow
numbers 1-4.

I whole heartidly believe you would be doing your group a disservice
by not helping them to understand the difference between a stub and
mock and you would probably hinder there ability to effectively use a
mocking framework or write good tests.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[ssteinegger]

I don't actually care about 'interaction based' or 'state-based'
definitions. Because you mostly don't have a choice. You have to test
what your unit under test is responsible for. If you want to test that
a service has been called, you need a mock with an expectation. If you
want to test the result of a calculation, you need to get this result.
Is it returned, it is easy. Is it only passed to another class, you
need a mock. Does the unit under test call services where you don't
care for a certain test, you can use a stub. And so on. You mostly
can't choose. If you can, you should ask yourself: which is the most
stable and secure and also easiest way to test it? To only test what's
important? However-based you'll call it.

Back to the topic: What is the difference in Rhino Mocks? Not in the
theory, we might all differ in our theories, guidelines and points of
view. If nobody actually knows the difference I'll read the code or
write some tests to find out. Actually, I don't have the time to do
this, but one day I have to know it well.

As a guess, it will be something like "Strict mocks only do what you
specify. Dynamic mocks accept calls that are not specified and (guess)
return default values. Stubs additionally have property behavior
defined for all properties" or something like this. If that's really
everything, then there isn't a big difference. You'll say: Do I want
do define PropertyBehavior() on all properties or just take a stub? Do
I want to define Repeat.Any or Repeat.Once on all methods or just take
dynamic mock or strict mock respectively? So it's just a matter of
writing less code.

On 10 Nov., 00:42, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> So the problem that I have with this is that you're really teaching them the
> wrong thing (using mocks) and they will later have to course correct.
>
> Since my talk was yesterday, and it went very well, here are the guidelines
> I gave:
>
>    - Favor GenerateStub over GenerateMock
>    - Favor state-based testing
>    - Use interaction based to test void method
>
> After talking to some new mock users the usage of stubs were easier for them
> (since you can treat just like a normal object with getters and setters).
>
> These guidelines are not my own but adopted from others out there.  I also
> feel it sets up beginners for less relearning later on.
>
> Tim
>
> On Sun, Nov 9, 2008 at 4:13 AM, shovavnik <[EMAIL PROTECTED]> wrote:
>
> > I also think of mocks as augmented stubs, but I think it's easier to
> > understand and teach mocks than stubs. Saying that perceptually a stub
> > is a mock without expectations (or the converse) doesn't really help
> > explain to beginners when or why to use either one.
>
> > Instead, I first make the claim: Mocks let you test expectations on
> > dependencies without writing code for mock classes. This is easy to
> > understand and demonstrate. I can replace a mocked class with a
> > dynamic mock to demonstrate it.
>
> > Then, if/when the issue comes up (probably more than a week later, if
> > ever), I can make a second claim: If you only want to satisfy a
> > dependency and not actually test it, use a stub instead; it's like a
> > mock without the expectations. This is easy to demonstrate because you
> > show how it works on real code. The problem comes up after the
> > programmers have come to realize (mental leap) that mocks are overkill
> > for certain scenarios. So it's easy to say: "You're right. It is
> > overkill. Use a stub instead."
>
> > I'd prefer a programmer start with mocks and get that down pat and
> > never learn about stubs, than start with both or with stubs only and
> > not use mocks properly or at all (out of confusion, learning curve).
>
> > shovavnik
>
> > On Nov 7, 2:28 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > > Going back through this thread makes me think that we, as people who use
> > > Rhino and contribute to helping others learn, need to clarify here the
> > > difference between Mocks and Stubs.  Stefan has contributed to the Rhino
> > > wiki and he admitted:
>
> > > Back to the original question: what is the difference between Rhino
> > > Mocksand Rhino
>
> > > > Stubs? I'm also confused and have to train the team. Until now, I
> > thought
> > > > that Stubs are DynamicMocks with PropertyBehaviour by default
> > (according
> > > > to the QuickReference 3.3).
>
> > > In your email (shovavnik) you say to introduce stubs after mocks, which
> > > seems a bit peculiar since I typically think of mocks as an augmented
> > > version of stubs, however I could be wrong.
>
> > > I'm wondering if we're getting to the point where the difference is
> > > irrelevant.  Obviously Fowler disagrees, but for the purposes of Rhino
> > I'm
> > > concerned that I can't explain the difference to a new user and neither
> > can
> > > many of you.  That's not an indictment on us, but rather it should be a
> > > warning sign that a barrier to entry exists.
>
> > > Tim
>
> > > On Mon, Oct 20, 2008 at 7:00 PM, sho

[RhinoMocks] Re: Mocks vs. Stubs

[Shane Courtrille]

I agree completely with this.  Your 3rd point actually follows the Command
Query separation principle which I find helps lead to easier to understand
code.

On Sun, Nov 9, 2008 at 4:42 PM, Tim Barcz <[EMAIL PROTECTED]> wrote:

> So the problem that I have with this is that you're really teaching them
> the wrong thing (using mocks) and they will later have to course correct.
>
> Since my talk was yesterday, and it went very well, here are the guidelines
> I gave:
>
>- Favor GenerateStub over GenerateMock
>- Favor state-based testing
>- Use interaction based to test void method
>
> After talking to some new mock users the usage of stubs were easier for
> them (since you can treat just like a normal object with getters and
> setters).
>
> These guidelines are not my own but adopted from others out there.  I also
> feel it sets up beginners for less relearning later on.
>
> Tim
>
>
> On Sun, Nov 9, 2008 at 4:13 AM, shovavnik <[EMAIL PROTECTED]> wrote:
>
>>
>> I also think of mocks as augmented stubs, but I think it's easier to
>> understand and teach mocks than stubs. Saying that perceptually a stub
>> is a mock without expectations (or the converse) doesn't really help
>> explain to beginners when or why to use either one.
>>
>> Instead, I first make the claim: Mocks let you test expectations on
>> dependencies without writing code for mock classes. This is easy to
>> understand and demonstrate. I can replace a mocked class with a
>> dynamic mock to demonstrate it.
>>
>> Then, if/when the issue comes up (probably more than a week later, if
>> ever), I can make a second claim: If you only want to satisfy a
>> dependency and not actually test it, use a stub instead; it's like a
>> mock without the expectations. This is easy to demonstrate because you
>> show how it works on real code. The problem comes up after the
>> programmers have come to realize (mental leap) that mocks are overkill
>> for certain scenarios. So it's easy to say: "You're right. It is
>> overkill. Use a stub instead."
>>
>> I'd prefer a programmer start with mocks and get that down pat and
>> never learn about stubs, than start with both or with stubs only and
>> not use mocks properly or at all (out of confusion, learning curve).
>>
>> shovavnik
>>
>> On Nov 7, 2:28 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
>> > Going back through this thread makes me think that we, as people who use
>> > Rhino and contribute to helping others learn, need to clarify here the
>> > difference between Mocks and Stubs.  Stefan has contributed to the Rhino
>> > wiki and he admitted:
>> >
>> > Back to the original question: what is the difference between Rhino
>> > Mocksand Rhino
>> >
>> > > Stubs? I'm also confused and have to train the team. Until now, I
>> thought
>> > > that Stubs are DynamicMocks with PropertyBehaviour by default
>> (according
>> > > to the QuickReference 3.3).
>> >
>> > In your email (shovavnik) you say to introduce stubs after mocks, which
>> > seems a bit peculiar since I typically think of mocks as an augmented
>> > version of stubs, however I could be wrong.
>> >
>> > I'm wondering if we're getting to the point where the difference is
>> > irrelevant.  Obviously Fowler disagrees, but for the purposes of Rhino
>> I'm
>> > concerned that I can't explain the difference to a new user and neither
>> can
>> > many of you.  That's not an indictment on us, but rather it should be a
>> > warning sign that a barrier to entry exists.
>> >
>> > Tim
>> >
>> > On Mon, Oct 20, 2008 at 7:00 PM, shovavnik <[EMAIL PROTECTED]> wrote:
>> >
>> > > Based on my relatively recent personal experience, I would suggest
>> > > taking a more pragmatic pedagogical approach.
>> >
>> > > When I talk about mocking to the uninitiated, I find it easiest to
>> > > follow this "mini-curriculum", based on increasing levels of
>> > > isolation.
>> >
>> > > 1. Show the problem. Don't talk about Record/Replay. Don't even
>> > > mention it exists. Explain AAA only. Use examples that have no stubs
>> > > or mocks to show the lack of isolation, brittle tests, complex
>> > > dependency construction for supposedly simple tests, etc. Those
>> > > interested will later find out about R/R on their own or will ask you
>> > > privately.
>> >
>> > > 2. Use mocks. Don't mention stubs exist. Don't go into detail about
>> > > stubs at all (neither mock.Stub() nor MockRepository.GenerateStub()).
>> > > The purpose of this step is to demonstrate that it's possible to
>> > > simplify the complexities inherent to the examples in the 1st step.
>> > > Don't set up expectations yet. Either leave in "real" objects or use
>> > > mocks where you would ordinarily use stubs.
>> >
>> > > 3. Set up expectations on your mocks to demonstrate testing and
>> > > isolating interactions.
>> >
>> > > 4. Introduce stubs if the programmers are comfortable with what
>> > > they've learned thus far. Show how stubs help further isolate the
>> > > tests and make them less brittle in a test that evolves 

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

So the problem that I have with this is that you're really teaching them the
wrong thing (using mocks) and they will later have to course correct.

Since my talk was yesterday, and it went very well, here are the guidelines
I gave:

   - Favor GenerateStub over GenerateMock
   - Favor state-based testing
   - Use interaction based to test void method

After talking to some new mock users the usage of stubs were easier for them
(since you can treat just like a normal object with getters and setters).

These guidelines are not my own but adopted from others out there.  I also
feel it sets up beginners for less relearning later on.

Tim

On Sun, Nov 9, 2008 at 4:13 AM, shovavnik <[EMAIL PROTECTED]> wrote:

>
> I also think of mocks as augmented stubs, but I think it's easier to
> understand and teach mocks than stubs. Saying that perceptually a stub
> is a mock without expectations (or the converse) doesn't really help
> explain to beginners when or why to use either one.
>
> Instead, I first make the claim: Mocks let you test expectations on
> dependencies without writing code for mock classes. This is easy to
> understand and demonstrate. I can replace a mocked class with a
> dynamic mock to demonstrate it.
>
> Then, if/when the issue comes up (probably more than a week later, if
> ever), I can make a second claim: If you only want to satisfy a
> dependency and not actually test it, use a stub instead; it's like a
> mock without the expectations. This is easy to demonstrate because you
> show how it works on real code. The problem comes up after the
> programmers have come to realize (mental leap) that mocks are overkill
> for certain scenarios. So it's easy to say: "You're right. It is
> overkill. Use a stub instead."
>
> I'd prefer a programmer start with mocks and get that down pat and
> never learn about stubs, than start with both or with stubs only and
> not use mocks properly or at all (out of confusion, learning curve).
>
> shovavnik
>
> On Nov 7, 2:28 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > Going back through this thread makes me think that we, as people who use
> > Rhino and contribute to helping others learn, need to clarify here the
> > difference between Mocks and Stubs.  Stefan has contributed to the Rhino
> > wiki and he admitted:
> >
> > Back to the original question: what is the difference between Rhino
> > Mocksand Rhino
> >
> > > Stubs? I'm also confused and have to train the team. Until now, I
> thought
> > > that Stubs are DynamicMocks with PropertyBehaviour by default
> (according
> > > to the QuickReference 3.3).
> >
> > In your email (shovavnik) you say to introduce stubs after mocks, which
> > seems a bit peculiar since I typically think of mocks as an augmented
> > version of stubs, however I could be wrong.
> >
> > I'm wondering if we're getting to the point where the difference is
> > irrelevant.  Obviously Fowler disagrees, but for the purposes of Rhino
> I'm
> > concerned that I can't explain the difference to a new user and neither
> can
> > many of you.  That's not an indictment on us, but rather it should be a
> > warning sign that a barrier to entry exists.
> >
> > Tim
> >
> > On Mon, Oct 20, 2008 at 7:00 PM, shovavnik <[EMAIL PROTECTED]> wrote:
> >
> > > Based on my relatively recent personal experience, I would suggest
> > > taking a more pragmatic pedagogical approach.
> >
> > > When I talk about mocking to the uninitiated, I find it easiest to
> > > follow this "mini-curriculum", based on increasing levels of
> > > isolation.
> >
> > > 1. Show the problem. Don't talk about Record/Replay. Don't even
> > > mention it exists. Explain AAA only. Use examples that have no stubs
> > > or mocks to show the lack of isolation, brittle tests, complex
> > > dependency construction for supposedly simple tests, etc. Those
> > > interested will later find out about R/R on their own or will ask you
> > > privately.
> >
> > > 2. Use mocks. Don't mention stubs exist. Don't go into detail about
> > > stubs at all (neither mock.Stub() nor MockRepository.GenerateStub()).
> > > The purpose of this step is to demonstrate that it's possible to
> > > simplify the complexities inherent to the examples in the 1st step.
> > > Don't set up expectations yet. Either leave in "real" objects or use
> > > mocks where you would ordinarily use stubs.
> >
> > > 3. Set up expectations on your mocks to demonstrate testing and
> > > isolating interactions.
> >
> > > 4. Introduce stubs if the programmers are comfortable with what
> > > they've learned thus far. Show how stubs help further isolate the
> > > tests and make them less brittle in a test that evolves between
> > > iterations. For example, if a new forking property is introduced, stub
> > > that property in an already-existing test to better describe the state
> > > of the SUT.
> >
> > > I find that walking programmers through this gradual process provides
> > > them with enough intuitive knowledge and confidence to start using it
> > > and le

[RhinoMocks] Re: Mocks vs. Stubs

[shovavnik]

I also think of mocks as augmented stubs, but I think it's easier to
understand and teach mocks than stubs. Saying that perceptually a stub
is a mock without expectations (or the converse) doesn't really help
explain to beginners when or why to use either one.

Instead, I first make the claim: Mocks let you test expectations on
dependencies without writing code for mock classes. This is easy to
understand and demonstrate. I can replace a mocked class with a
dynamic mock to demonstrate it.

Then, if/when the issue comes up (probably more than a week later, if
ever), I can make a second claim: If you only want to satisfy a
dependency and not actually test it, use a stub instead; it's like a
mock without the expectations. This is easy to demonstrate because you
show how it works on real code. The problem comes up after the
programmers have come to realize (mental leap) that mocks are overkill
for certain scenarios. So it's easy to say: "You're right. It is
overkill. Use a stub instead."

I'd prefer a programmer start with mocks and get that down pat and
never learn about stubs, than start with both or with stubs only and
not use mocks properly or at all (out of confusion, learning curve).

shovavnik

On Nov 7, 2:28 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> Going back through this thread makes me think that we, as people who use
> Rhino and contribute to helping others learn, need to clarify here the
> difference between Mocks and Stubs.  Stefan has contributed to the Rhino
> wiki and he admitted:
>
> Back to the original question: what is the difference between Rhino
> Mocksand Rhino
>
> > Stubs? I'm also confused and have to train the team. Until now, I thought
> > that Stubs are DynamicMocks with PropertyBehaviour by default (according
> > to the QuickReference 3.3).
>
> In your email (shovavnik) you say to introduce stubs after mocks, which
> seems a bit peculiar since I typically think of mocks as an augmented
> version of stubs, however I could be wrong.
>
> I'm wondering if we're getting to the point where the difference is
> irrelevant.  Obviously Fowler disagrees, but for the purposes of Rhino I'm
> concerned that I can't explain the difference to a new user and neither can
> many of you.  That's not an indictment on us, but rather it should be a
> warning sign that a barrier to entry exists.
>
> Tim
>
> On Mon, Oct 20, 2008 at 7:00 PM, shovavnik <[EMAIL PROTECTED]> wrote:
>
> > Based on my relatively recent personal experience, I would suggest
> > taking a more pragmatic pedagogical approach.
>
> > When I talk about mocking to the uninitiated, I find it easiest to
> > follow this "mini-curriculum", based on increasing levels of
> > isolation.
>
> > 1. Show the problem. Don't talk about Record/Replay. Don't even
> > mention it exists. Explain AAA only. Use examples that have no stubs
> > or mocks to show the lack of isolation, brittle tests, complex
> > dependency construction for supposedly simple tests, etc. Those
> > interested will later find out about R/R on their own or will ask you
> > privately.
>
> > 2. Use mocks. Don't mention stubs exist. Don't go into detail about
> > stubs at all (neither mock.Stub() nor MockRepository.GenerateStub()).
> > The purpose of this step is to demonstrate that it's possible to
> > simplify the complexities inherent to the examples in the 1st step.
> > Don't set up expectations yet. Either leave in "real" objects or use
> > mocks where you would ordinarily use stubs.
>
> > 3. Set up expectations on your mocks to demonstrate testing and
> > isolating interactions.
>
> > 4. Introduce stubs if the programmers are comfortable with what
> > they've learned thus far. Show how stubs help further isolate the
> > tests and make them less brittle in a test that evolves between
> > iterations. For example, if a new forking property is introduced, stub
> > that property in an already-existing test to better describe the state
> > of the SUT.
>
> > I find that walking programmers through this gradual process provides
> > them with enough intuitive knowledge and confidence to start using it
> > and learning more on their own. Some will get stuck on the mocks and
> > others will start drilling you about the finer points of distinction.
> > The latter can be referred to the source code.
>
> > On Oct 20, 10:33 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > > Testing is hard, but that doesn't mean we can try to distill it into
> > > manageable chunks.  A true professional can take something complex and
> > make
> > > it sound simple.
>
> > > Tim
>
> > > On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <
> > [EMAIL PROTECTED]
>
> > > > wrote:
> > > > The problem I see with that is that you're putting a tool into their
> > hands
> > > > without them
> > > > really understanding the basic concepts.  At the end of the day testing
> > is
> > > > not easy.
>
> > > > There are some concepts that people need to understand.  State vs
> > > > Interaction testing
> > > > is a very big d

[RhinoMocks] Re: Mocks vs. Stubs

[Shane Courtrille]

To me a stub is used to provide dependencies that a piece of code has.  It
calls X and needs Y returned.

A mock on the other hand is used for interaction based testing.  My code
calls off to my repository to save an object.  The only way to test this
action (in a unit test as opposed to an integration test which should call
out to the live db) is to verify that the actual call is being made to the
repository.  In this case I mock out the repository and set an expectation
which I can then verify.

Shane

On Fri, Nov 7, 2008 at 5:28 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:

> Going back through this thread makes me think that we, as people who use
> Rhino and contribute to helping others learn, need to clarify here the
> difference between Mocks and Stubs.  Stefan has contributed to the Rhino
> wiki and he admitted:
>
> Back to the original question: what is the difference between Rhino Mocksand 
> Rhino
>> Stubs? I'm also confused and have to train the team. Until now, I thought
>> that Stubs are DynamicMocks with PropertyBehaviour by default (according
>> to the QuickReference 3.3).
>
>
> In your email (shovavnik) you say to introduce stubs after mocks, which
> seems a bit peculiar since I typically think of mocks as an augmented
> version of stubs, however I could be wrong.
>
> I'm wondering if we're getting to the point where the difference is
> irrelevant.  Obviously Fowler disagrees, but for the purposes of Rhino I'm
> concerned that I can't explain the difference to a new user and neither can
> many of you.  That's not an indictment on us, but rather it should be a
> warning sign that a barrier to entry exists.
>
> Tim
>
>
> On Mon, Oct 20, 2008 at 7:00 PM, shovavnik <[EMAIL PROTECTED]> wrote:
>
>>
>> Based on my relatively recent personal experience, I would suggest
>> taking a more pragmatic pedagogical approach.
>>
>> When I talk about mocking to the uninitiated, I find it easiest to
>> follow this "mini-curriculum", based on increasing levels of
>> isolation.
>>
>> 1. Show the problem. Don't talk about Record/Replay. Don't even
>> mention it exists. Explain AAA only. Use examples that have no stubs
>> or mocks to show the lack of isolation, brittle tests, complex
>> dependency construction for supposedly simple tests, etc. Those
>> interested will later find out about R/R on their own or will ask you
>> privately.
>>
>> 2. Use mocks. Don't mention stubs exist. Don't go into detail about
>> stubs at all (neither mock.Stub() nor MockRepository.GenerateStub()).
>> The purpose of this step is to demonstrate that it's possible to
>> simplify the complexities inherent to the examples in the 1st step.
>> Don't set up expectations yet. Either leave in "real" objects or use
>> mocks where you would ordinarily use stubs.
>>
>> 3. Set up expectations on your mocks to demonstrate testing and
>> isolating interactions.
>>
>> 4. Introduce stubs if the programmers are comfortable with what
>> they've learned thus far. Show how stubs help further isolate the
>> tests and make them less brittle in a test that evolves between
>> iterations. For example, if a new forking property is introduced, stub
>> that property in an already-existing test to better describe the state
>> of the SUT.
>>
>> I find that walking programmers through this gradual process provides
>> them with enough intuitive knowledge and confidence to start using it
>> and learning more on their own. Some will get stuck on the mocks and
>> others will start drilling you about the finer points of distinction.
>> The latter can be referred to the source code.
>>
>>
>> On Oct 20, 10:33 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
>> > Testing is hard, but that doesn't mean we can try to distill it into
>> > manageable chunks.  A true professional can take something complex and
>> make
>> > it sound simple.
>> >
>> > Tim
>> >
>> > On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <
>> [EMAIL PROTECTED]
>> >
>> > > wrote:
>> > > The problem I see with that is that you're putting a tool into their
>> hands
>> > > without them
>> > > really understanding the basic concepts.  At the end of the day
>> testing is
>> > > not easy.
>> >
>> > > There are some concepts that people need to understand.  State vs
>> > > Interaction testing
>> > > is a very big deal and I think that Stub vs Mock is where the two are
>> > > separated.  If you are
>> > > trying to teach people about Rhino Mocks without starting them off
>> with an
>> > > explanation
>> > > as to the different type of testing (aka State vs Interaction) and
>> where
>> > > uses one vs the other
>> > > then you are missing a valuable chance to increase their knowledge.
>> >
>> > > On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]>
>> wrote:
>> >
>> > >> Good pointforgot about PropertyBehavior (but in this case isn't
>> that
>> > >> behavior on a stub an augmentation of a mock's behavior?  On the
>> Rhino site
>> > >> it says you can do property behavior but that it gets tedious, so
>> inste

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

Going back through this thread makes me think that we, as people who use
Rhino and contribute to helping others learn, need to clarify here the
difference between Mocks and Stubs.  Stefan has contributed to the Rhino
wiki and he admitted:

Back to the original question: what is the difference between Rhino
Mocksand Rhino
> Stubs? I'm also confused and have to train the team. Until now, I thought
> that Stubs are DynamicMocks with PropertyBehaviour by default (according
> to the QuickReference 3.3).


In your email (shovavnik) you say to introduce stubs after mocks, which
seems a bit peculiar since I typically think of mocks as an augmented
version of stubs, however I could be wrong.

I'm wondering if we're getting to the point where the difference is
irrelevant.  Obviously Fowler disagrees, but for the purposes of Rhino I'm
concerned that I can't explain the difference to a new user and neither can
many of you.  That's not an indictment on us, but rather it should be a
warning sign that a barrier to entry exists.

Tim


On Mon, Oct 20, 2008 at 7:00 PM, shovavnik <[EMAIL PROTECTED]> wrote:

>
> Based on my relatively recent personal experience, I would suggest
> taking a more pragmatic pedagogical approach.
>
> When I talk about mocking to the uninitiated, I find it easiest to
> follow this "mini-curriculum", based on increasing levels of
> isolation.
>
> 1. Show the problem. Don't talk about Record/Replay. Don't even
> mention it exists. Explain AAA only. Use examples that have no stubs
> or mocks to show the lack of isolation, brittle tests, complex
> dependency construction for supposedly simple tests, etc. Those
> interested will later find out about R/R on their own or will ask you
> privately.
>
> 2. Use mocks. Don't mention stubs exist. Don't go into detail about
> stubs at all (neither mock.Stub() nor MockRepository.GenerateStub()).
> The purpose of this step is to demonstrate that it's possible to
> simplify the complexities inherent to the examples in the 1st step.
> Don't set up expectations yet. Either leave in "real" objects or use
> mocks where you would ordinarily use stubs.
>
> 3. Set up expectations on your mocks to demonstrate testing and
> isolating interactions.
>
> 4. Introduce stubs if the programmers are comfortable with what
> they've learned thus far. Show how stubs help further isolate the
> tests and make them less brittle in a test that evolves between
> iterations. For example, if a new forking property is introduced, stub
> that property in an already-existing test to better describe the state
> of the SUT.
>
> I find that walking programmers through this gradual process provides
> them with enough intuitive knowledge and confidence to start using it
> and learning more on their own. Some will get stuck on the mocks and
> others will start drilling you about the finer points of distinction.
> The latter can be referred to the source code.
>
>
> On Oct 20, 10:33 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > Testing is hard, but that doesn't mean we can try to distill it into
> > manageable chunks.  A true professional can take something complex and
> make
> > it sound simple.
> >
> > Tim
> >
> > On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <
> [EMAIL PROTECTED]
> >
> > > wrote:
> > > The problem I see with that is that you're putting a tool into their
> hands
> > > without them
> > > really understanding the basic concepts.  At the end of the day testing
> is
> > > not easy.
> >
> > > There are some concepts that people need to understand.  State vs
> > > Interaction testing
> > > is a very big deal and I think that Stub vs Mock is where the two are
> > > separated.  If you are
> > > trying to teach people about Rhino Mocks without starting them off with
> an
> > > explanation
> > > as to the different type of testing (aka State vs Interaction) and
> where
> > > uses one vs the other
> > > then you are missing a valuable chance to increase their knowledge.
> >
> > > On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
> >
> > >> Good pointforgot about PropertyBehavior (but in this case isn't
> that
> > >> behavior on a stub an augmentation of a mock's behavior?  On the Rhino
> site
> > >> it says you can do property behavior but that it gets tedious, so
> instead
> > >> you can just do a stub.)
> >
> > >> I was hoping to simplify the concepts for the attendees of my Rhino
> > >> presentation.  That's the goal, to get more people testing with Rhino.
> >
> > >> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
> >
> > >>> then i think it is too oversimplified. stubs in rhino are optimized
> to
> > >>> behave as closely as possible to real objects that are being faked.
> > >>> this means that stubs maintain state for properties for example
> > >>> (PropertyBehaviour).
> >
> > >>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > >>> > I'm familiar with the fowler article and mocking in general...I'm
> > >>> talking in
> > >>

[RhinoMocks] Re: Mocks vs. Stubs

[shovavnik]

Based on my relatively recent personal experience, I would suggest
taking a more pragmatic pedagogical approach.

When I talk about mocking to the uninitiated, I find it easiest to
follow this "mini-curriculum", based on increasing levels of
isolation.

1. Show the problem. Don't talk about Record/Replay. Don't even
mention it exists. Explain AAA only. Use examples that have no stubs
or mocks to show the lack of isolation, brittle tests, complex
dependency construction for supposedly simple tests, etc. Those
interested will later find out about R/R on their own or will ask you
privately.

2. Use mocks. Don't mention stubs exist. Don't go into detail about
stubs at all (neither mock.Stub() nor MockRepository.GenerateStub()).
The purpose of this step is to demonstrate that it's possible to
simplify the complexities inherent to the examples in the 1st step.
Don't set up expectations yet. Either leave in "real" objects or use
mocks where you would ordinarily use stubs.

3. Set up expectations on your mocks to demonstrate testing and
isolating interactions.

4. Introduce stubs if the programmers are comfortable with what
they've learned thus far. Show how stubs help further isolate the
tests and make them less brittle in a test that evolves between
iterations. For example, if a new forking property is introduced, stub
that property in an already-existing test to better describe the state
of the SUT.

I find that walking programmers through this gradual process provides
them with enough intuitive knowledge and confidence to start using it
and learning more on their own. Some will get stuck on the mocks and
others will start drilling you about the finer points of distinction.
The latter can be referred to the source code.


On Oct 20, 10:33 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> Testing is hard, but that doesn't mean we can try to distill it into
> manageable chunks.  A true professional can take something complex and make
> it sound simple.
>
> Tim
>
> On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <[EMAIL PROTECTED]
>
> > wrote:
> > The problem I see with that is that you're putting a tool into their hands
> > without them
> > really understanding the basic concepts.  At the end of the day testing is
> > not easy.
>
> > There are some concepts that people need to understand.  State vs
> > Interaction testing
> > is a very big deal and I think that Stub vs Mock is where the two are
> > separated.  If you are
> > trying to teach people about Rhino Mocks without starting them off with an
> > explanation
> > as to the different type of testing (aka State vs Interaction) and where
> > uses one vs the other
> > then you are missing a valuable chance to increase their knowledge.
>
> > On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
> >> Good pointforgot about PropertyBehavior (but in this case isn't that
> >> behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
> >> it says you can do property behavior but that it gets tedious, so instead
> >> you can just do a stub.)
>
> >> I was hoping to simplify the concepts for the attendees of my Rhino
> >> presentation.  That's the goal, to get more people testing with Rhino.
>
> >> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>
> >>> then i think it is too oversimplified. stubs in rhino are optimized to
> >>> behave as closely as possible to real objects that are being faked.
> >>> this means that stubs maintain state for properties for example
> >>> (PropertyBehaviour).
>
> >>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> >>> > I'm familiar with the fowler article and mocking in general...I'm
> >>> talking in
> >>> > terms of Rhino
>
> >>> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> >>> [EMAIL PROTECTED]
>
> >>> > > wrote:
> >>> > > I'd recommend you start here...
>
> >>> > >http://martinfowler.com/articles/mocksArentStubs.html
>
> >>> > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
> >>> wrote:
>
> >>> > >> Am working on a code camp presentation and am trying to distill the
> >>> > >> subject of mocking with Rhino down to the easiest possible concepts
> >>> I can
> >>> > >> think of.
>
> >>> > >> Would you say the following statement is true or false?
>
> >>> > >> Mocks and stubs are the same, except that you can put an expectation
> >>> on a
> >>> > >> mock.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[ssteinegger]

Back to the original question: what is the difference between Rhino
Mocks and Rhino Stubs? I'm also confused and have to train the team.
Until now, I thought that Stubs are DynamicMocks with
PropertyBehaviour by default (according to the QuickReference 3.3).
Expectations to a Stub is somehow weird for me, but that's probably
just because of Fowlers definition.

Here is Ayendes documentation to 3.5:
http://ayende.com/Wiki/Rhino+Mocks+3.5.ashx#Thedifferencebetweenstubsandmocks

In the examples he creates stubs and then tests with AssertWasCalled.
In my case, that would be very powerful. We have a testing-framework,
where many infrastructure service are registered. Many of them are
just Stubs or Null-objects. So if someone wants to define an
expectation (for instance to ITransactionService.Commit), he has to
replace it with a mock. It is MUCH nicer if he just writes
AssertWasCalled. I mean: when I _create_ the mock / stub, I don't have
to know if the test expects anything on it. This reduces code a lot,
because I don't have to create the mocks in every test. That's the
power of AAA. The first A doesn't need to be part of a single test.

There is this sentence in the documentation: "IMPORTANT: A stub will
never cause a test to fail." For me, this is very confusing and I
wanted already to ask Ayende what it means. It should probably mean "A
stub will never throw any exceptions when replaying" or something.
Doesn't this also apply to dynamic mocks?

On 20 Okt., 22:59, Mark Allen <[EMAIL PROTECTED]> wrote:
> My group as well has been struggling with the distinction between
> Mocks and Stubs. We have been using Rhino Mocks for about 6 months now
> with the Record/Playback semantics, and we are now adopting the AAA
> style. I have been trying to define guidelines for when it is
> appropriate to use Mock vs Stub, but have failed to find the divining
> rod. In perusing the literature (e.g. Fowler) and blog posts, I would
> have thought that Stubs would not have an ability to .Expect
> or .Assert. Instead, Stubs would just support the ability to stub data
> and behavior.
>
> I've tried to define usage of these as follows :
> Stubs are the "uninteresting" part of the test case. Simply, stubs are
> used to inject state into a test case, but their interaction is not
> being tested. Thus, you should not .Expect or .Assert on a stub.
> Mocks, on the other hand, are the "interesting" part of the test case,
> as they are part of the interaction being tested.
>
> Am I way off here? I know that in Ayende's documentation, he suggests
> that stubs would mostly be used. So I am a bit confused as to the fine
> line between Mock and Stub usage.
>
> On Oct 20, 4:33 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
>
> > Testing is hard, but that doesn't mean we can try to distill it into
> > manageable chunks.  A true professional can take something complex and make
> > it sound simple.
>
> > Tim
>
> > On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <[EMAIL PROTECTED]
>
> > > wrote:
> > > The problem I see with that is that you're putting a tool into their hands
> > > without them
> > > really understanding the basic concepts.  At the end of the day testing is
> > > not easy.
>
> > > There are some concepts that people need to understand.  State vs
> > > Interaction testing
> > > is a very big deal and I think that Stub vs Mock is where the two are
> > > separated.  If you are
> > > trying to teach people about Rhino Mocks without starting them off with an
> > > explanation
> > > as to the different type of testing (aka State vs Interaction) and where
> > > uses one vs the other
> > > then you are missing a valuable chance to increase their knowledge.
>
> > > On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
> > >> Good pointforgot about PropertyBehavior (but in this case isn't that
> > >> behavior on a stub an augmentation of a mock's behavior?  On the Rhino 
> > >> site
> > >> it says you can do property behavior but that it gets tedious, so instead
> > >> you can just do a stub.)
>
> > >> I was hoping to simplify the concepts for the attendees of my Rhino
> > >> presentation.  That's the goal, to get more people testing with Rhino.
>
> > >> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>
> > >>> then i think it is too oversimplified. stubs in rhino are optimized to
> > >>> behave as closely as possible to real objects that are being faked.
> > >>> this means that stubs maintain state for properties for example
> > >>> (PropertyBehaviour).
>
> > >>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > >>> > I'm familiar with the fowler article and mocking in general...I'm
> > >>> talking in
> > >>> > terms of Rhino
>
> > >>> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> > >>> [EMAIL PROTECTED]
>
> > >>> > > wrote:
> > >>> > > I'd recommend you start here...
>
> > >>> > >http://martinfowler.com/articles/mocksArentStubs.html
>
> > >>> > > On Mon, Oct 20, 2008 at 6:0

[RhinoMocks] Re: Mocks vs. Stubs

[Mark Allen]

My group as well has been struggling with the distinction between
Mocks and Stubs. We have been using Rhino Mocks for about 6 months now
with the Record/Playback semantics, and we are now adopting the AAA
style. I have been trying to define guidelines for when it is
appropriate to use Mock vs Stub, but have failed to find the divining
rod. In perusing the literature (e.g. Fowler) and blog posts, I would
have thought that Stubs would not have an ability to .Expect
or .Assert. Instead, Stubs would just support the ability to stub data
and behavior.

I've tried to define usage of these as follows :
Stubs are the "uninteresting" part of the test case. Simply, stubs are
used to inject state into a test case, but their interaction is not
being tested. Thus, you should not .Expect or .Assert on a stub.
Mocks, on the other hand, are the "interesting" part of the test case,
as they are part of the interaction being tested.

Am I way off here? I know that in Ayende's documentation, he suggests
that stubs would mostly be used. So I am a bit confused as to the fine
line between Mock and Stub usage.

On Oct 20, 4:33 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> Testing is hard, but that doesn't mean we can try to distill it into
> manageable chunks.  A true professional can take something complex and make
> it sound simple.
>
> Tim
>
> On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <[EMAIL PROTECTED]
>
> > wrote:
> > The problem I see with that is that you're putting a tool into their hands
> > without them
> > really understanding the basic concepts.  At the end of the day testing is
> > not easy.
>
> > There are some concepts that people need to understand.  State vs
> > Interaction testing
> > is a very big deal and I think that Stub vs Mock is where the two are
> > separated.  If you are
> > trying to teach people about Rhino Mocks without starting them off with an
> > explanation
> > as to the different type of testing (aka State vs Interaction) and where
> > uses one vs the other
> > then you are missing a valuable chance to increase their knowledge.
>
> > On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
> >> Good pointforgot about PropertyBehavior (but in this case isn't that
> >> behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
> >> it says you can do property behavior but that it gets tedious, so instead
> >> you can just do a stub.)
>
> >> I was hoping to simplify the concepts for the attendees of my Rhino
> >> presentation.  That's the goal, to get more people testing with Rhino.
>
> >> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>
> >>> then i think it is too oversimplified. stubs in rhino are optimized to
> >>> behave as closely as possible to real objects that are being faked.
> >>> this means that stubs maintain state for properties for example
> >>> (PropertyBehaviour).
>
> >>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> >>> > I'm familiar with the fowler article and mocking in general...I'm
> >>> talking in
> >>> > terms of Rhino
>
> >>> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> >>> [EMAIL PROTECTED]
>
> >>> > > wrote:
> >>> > > I'd recommend you start here...
>
> >>> > >http://martinfowler.com/articles/mocksArentStubs.html
>
> >>> > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
> >>> wrote:
>
> >>> > >> Am working on a code camp presentation and am trying to distill the
> >>> > >> subject of mocking with Rhino down to the easiest possible concepts
> >>> I can
> >>> > >> think of.
>
> >>> > >> Would you say the following statement is true or false?
>
> >>> > >> Mocks and stubs are the same, except that you can put an expectation
> >>> on a
> >>> > >> mock.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

Testing is hard, but that doesn't mean we can try to distill it into
manageable chunks.  A true professional can take something complex and make
it sound simple.

Tim

On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <[EMAIL PROTECTED]
> wrote:

> The problem I see with that is that you're putting a tool into their hands
> without them
> really understanding the basic concepts.  At the end of the day testing is
> not easy.
>
> There are some concepts that people need to understand.  State vs
> Interaction testing
> is a very big deal and I think that Stub vs Mock is where the two are
> separated.  If you are
> trying to teach people about Rhino Mocks without starting them off with an
> explanation
> as to the different type of testing (aka State vs Interaction) and where
> uses one vs the other
> then you are missing a valuable chance to increase their knowledge.
>
>
> On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
>> Good pointforgot about PropertyBehavior (but in this case isn't that
>> behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
>> it says you can do property behavior but that it gets tedious, so instead
>> you can just do a stub.)
>>
>> I was hoping to simplify the concepts for the attendees of my Rhino
>> presentation.  That's the goal, to get more people testing with Rhino.
>>
>>
>>
>> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> then i think it is too oversimplified. stubs in rhino are optimized to
>>> behave as closely as possible to real objects that are being faked.
>>> this means that stubs maintain state for properties for example
>>> (PropertyBehaviour).
>>>
>>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
>>> > I'm familiar with the fowler article and mocking in general...I'm
>>> talking in
>>> > terms of Rhino
>>> >
>>> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
>>> [EMAIL PROTECTED]
>>> >
>>> > > wrote:
>>> > > I'd recommend you start here...
>>> >
>>> > >http://martinfowler.com/articles/mocksArentStubs.html
>>> >
>>> > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
>>> wrote:
>>> >
>>> > >> Am working on a code camp presentation and am trying to distill the
>>> > >> subject of mocking with Rhino down to the easiest possible concepts
>>> I can
>>> > >> think of.
>>> >
>>> > >> Would you say the following statement is true or false?
>>> >
>>> > >> Mocks and stubs are the same, except that you can put an expectation
>>> on a
>>> > >> mock.
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

I am talking about the differences between state and interactions, however
for the vast majority of cases I believe that interaction based test are
over used.

However I am going to cover it.



On Mon, Oct 20, 2008 at 3:06 PM, Shane Courtrille <[EMAIL PROTECTED]
> wrote:

> The problem I see with that is that you're putting a tool into their hands
> without them
> really understanding the basic concepts.  At the end of the day testing is
> not easy.
>
> There are some concepts that people need to understand.  State vs
> Interaction testing
> is a very big deal and I think that Stub vs Mock is where the two are
> separated.  If you are
> trying to teach people about Rhino Mocks without starting them off with an
> explanation
> as to the different type of testing (aka State vs Interaction) and where
> uses one vs the other
> then you are missing a valuable chance to increase their knowledge.
>
>
> On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
>> Good pointforgot about PropertyBehavior (but in this case isn't that
>> behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
>> it says you can do property behavior but that it gets tedious, so instead
>> you can just do a stub.)
>>
>> I was hoping to simplify the concepts for the attendees of my Rhino
>> presentation.  That's the goal, to get more people testing with Rhino.
>>
>>
>>
>> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> then i think it is too oversimplified. stubs in rhino are optimized to
>>> behave as closely as possible to real objects that are being faked.
>>> this means that stubs maintain state for properties for example
>>> (PropertyBehaviour).
>>>
>>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
>>> > I'm familiar with the fowler article and mocking in general...I'm
>>> talking in
>>> > terms of Rhino
>>> >
>>> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
>>> [EMAIL PROTECTED]
>>> >
>>> > > wrote:
>>> > > I'd recommend you start here...
>>> >
>>> > >http://martinfowler.com/articles/mocksArentStubs.html
>>> >
>>> > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
>>> wrote:
>>> >
>>> > >> Am working on a code camp presentation and am trying to distill the
>>> > >> subject of mocking with Rhino down to the easiest possible concepts
>>> I can
>>> > >> think of.
>>> >
>>> > >> Would you say the following statement is true or false?
>>> >
>>> > >> Mocks and stubs are the same, except that you can put an expectation
>>> on a
>>> > >> mock.
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Shane Courtrille]

The problem I see with that is that you're putting a tool into their hands
without them
really understanding the basic concepts.  At the end of the day testing is
not easy.

There are some concepts that people need to understand.  State vs
Interaction testing
is a very big deal and I think that Stub vs Mock is where the two are
separated.  If you are
trying to teach people about Rhino Mocks without starting them off with an
explanation
as to the different type of testing (aka State vs Interaction) and where
uses one vs the other
then you are missing a valuable chance to increase their knowledge.

On Mon, Oct 20, 2008 at 9:37 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:

> Good pointforgot about PropertyBehavior (but in this case isn't that
> behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
> it says you can do property behavior but that it gets tedious, so instead
> you can just do a stub.)
>
> I was hoping to simplify the concepts for the attendees of my Rhino
> presentation.  That's the goal, to get more people testing with Rhino.
>
>
>
> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>
>>
>> then i think it is too oversimplified. stubs in rhino are optimized to
>> behave as closely as possible to real objects that are being faked.
>> this means that stubs maintain state for properties for example
>> (PropertyBehaviour).
>>
>> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
>> > I'm familiar with the fowler article and mocking in general...I'm
>> talking in
>> > terms of Rhino
>> >
>> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
>> [EMAIL PROTECTED]
>> >
>> > > wrote:
>> > > I'd recommend you start here...
>> >
>> > >http://martinfowler.com/articles/mocksArentStubs.html
>> >
>> > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
>> wrote:
>> >
>> > >> Am working on a code camp presentation and am trying to distill the
>> > >> subject of mocking with Rhino down to the easiest possible concepts I
>> can
>> > >> think of.
>> >
>> > >> Would you say the following statement is true or false?
>> >
>> > >> Mocks and stubs are the same, except that you can put an expectation
>> on a
>> > >> mock.
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[naraga]

yes! some times it gives you great flexibility and it is not wise to
avoid it completelly.
but for many cases it is much more simpler to let system generate
smart box for me.

On Oct 20, 9:32 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> define your usage of "test doubles"do you mean "hand written
> mocks/stubs"?
>
> On Mon, Oct 20, 2008 at 2:26 PM, naraga <[EMAIL PROTECTED]> wrote:
>
> > i think you are right. maybe ayende has more to say about this ...
> > btw. who are your attendees? people aware of mocking as general
> > topic?
> > from my experience when i jumped into Rhino on my presentations to
> > people with no experience
> > then it everytime ended up with wierd face expressions :)
> > so last time i tried to mention Rhino only slightly at the end of the
> > presentation when everyone agreed that amount of code
> > i had to write to create test-doubles was just too big.
>
> > On Oct 20, 5:37 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > > Good pointforgot about PropertyBehavior (but in this case isn't that
> > > behavior on a stub an augmentation of a mock's behavior?  On the Rhino
> > site
> > > it says you can do property behavior but that it gets tedious, so instead
> > > you can just do a stub.)
>
> > > I was hoping to simplify the concepts for the attendees of my Rhino
> > > presentation.  That's the goal, to get more people testing with Rhino.
>
> > > On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>
> > > > then i think it is too oversimplified. stubs in rhino are optimized to
> > > > behave as closely as possible to real objects that are being faked.
> > > > this means that stubs maintain state for properties for example
> > > > (PropertyBehaviour).
>
> > > > On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > > > > I'm familiar with the fowler article and mocking in general...I'm
> > talking
> > > > in
> > > > > terms of Rhino
>
> > > > > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> > > > [EMAIL PROTECTED]
>
> > > > > > wrote:
> > > > > > I'd recommend you start here...
>
> > > > > >http://martinfowler.com/articles/mocksArentStubs.html
>
> > > > > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
> > wrote:
>
> > > > > >> Am working on a code camp presentation and am trying to distill
> > the
> > > > > >> subject of mocking with Rhino down to the easiest possible
> > concepts I
> > > > can
> > > > > >> think of.
>
> > > > > >> Would you say the following statement is true or false?
>
> > > > > >> Mocks and stubs are the same, except that you can put an
> > expectation
> > > > on a
> > > > > >> mock.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

define your usage of "test doubles"do you mean "hand written
mocks/stubs"?

On Mon, Oct 20, 2008 at 2:26 PM, naraga <[EMAIL PROTECTED]> wrote:

>
> i think you are right. maybe ayende has more to say about this ...
> btw. who are your attendees? people aware of mocking as general
> topic?
> from my experience when i jumped into Rhino on my presentations to
> people with no experience
> then it everytime ended up with wierd face expressions :)
> so last time i tried to mention Rhino only slightly at the end of the
> presentation when everyone agreed that amount of code
> i had to write to create test-doubles was just too big.
>
> On Oct 20, 5:37 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > Good pointforgot about PropertyBehavior (but in this case isn't that
> > behavior on a stub an augmentation of a mock's behavior?  On the Rhino
> site
> > it says you can do property behavior but that it gets tedious, so instead
> > you can just do a stub.)
> >
> > I was hoping to simplify the concepts for the attendees of my Rhino
> > presentation.  That's the goal, to get more people testing with Rhino.
> >
> > On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
> >
> > > then i think it is too oversimplified. stubs in rhino are optimized to
> > > behave as closely as possible to real objects that are being faked.
> > > this means that stubs maintain state for properties for example
> > > (PropertyBehaviour).
> >
> > > On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > > > I'm familiar with the fowler article and mocking in general...I'm
> talking
> > > in
> > > > terms of Rhino
> >
> > > > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> > > [EMAIL PROTECTED]
> >
> > > > > wrote:
> > > > > I'd recommend you start here...
> >
> > > > >http://martinfowler.com/articles/mocksArentStubs.html
> >
> > > > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]>
> wrote:
> >
> > > > >> Am working on a code camp presentation and am trying to distill
> the
> > > > >> subject of mocking with Rhino down to the easiest possible
> concepts I
> > > can
> > > > >> think of.
> >
> > > > >> Would you say the following statement is true or false?
> >
> > > > >> Mocks and stubs are the same, except that you can put an
> expectation
> > > on a
> > > > >> mock.
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[naraga]

i think you are right. maybe ayende has more to say about this ...
btw. who are your attendees? people aware of mocking as general
topic?
from my experience when i jumped into Rhino on my presentations to
people with no experience
then it everytime ended up with wierd face expressions :)
so last time i tried to mention Rhino only slightly at the end of the
presentation when everyone agreed that amount of code
i had to write to create test-doubles was just too big.

On Oct 20, 5:37 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> Good pointforgot about PropertyBehavior (but in this case isn't that
> behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
> it says you can do property behavior but that it gets tedious, so instead
> you can just do a stub.)
>
> I was hoping to simplify the concepts for the attendees of my Rhino
> presentation.  That's the goal, to get more people testing with Rhino.
>
> On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:
>
> > then i think it is too oversimplified. stubs in rhino are optimized to
> > behave as closely as possible to real objects that are being faked.
> > this means that stubs maintain state for properties for example
> > (PropertyBehaviour).
>
> > On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > > I'm familiar with the fowler article and mocking in general...I'm talking
> > in
> > > terms of Rhino
>
> > > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> > [EMAIL PROTECTED]
>
> > > > wrote:
> > > > I'd recommend you start here...
>
> > > >http://martinfowler.com/articles/mocksArentStubs.html
>
> > > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
> > > >> Am working on a code camp presentation and am trying to distill the
> > > >> subject of mocking with Rhino down to the easiest possible concepts I
> > can
> > > >> think of.
>
> > > >> Would you say the following statement is true or false?
>
> > > >> Mocks and stubs are the same, except that you can put an expectation
> > on a
> > > >> mock.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

Good pointforgot about PropertyBehavior (but in this case isn't that
behavior on a stub an augmentation of a mock's behavior?  On the Rhino site
it says you can do property behavior but that it gets tedious, so instead
you can just do a stub.)

I was hoping to simplify the concepts for the attendees of my Rhino
presentation.  That's the goal, to get more people testing with Rhino.


On Mon, Oct 20, 2008 at 10:26 AM, naraga <[EMAIL PROTECTED]> wrote:

>
> then i think it is too oversimplified. stubs in rhino are optimized to
> behave as closely as possible to real objects that are being faked.
> this means that stubs maintain state for properties for example
> (PropertyBehaviour).
>
> On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > I'm familiar with the fowler article and mocking in general...I'm talking
> in
> > terms of Rhino
> >
> > On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <
> [EMAIL PROTECTED]
> >
> > > wrote:
> > > I'd recommend you start here...
> >
> > >http://martinfowler.com/articles/mocksArentStubs.html
> >
> > > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
> >
> > >> Am working on a code camp presentation and am trying to distill the
> > >> subject of mocking with Rhino down to the easiest possible concepts I
> can
> > >> think of.
> >
> > >> Would you say the following statement is true or false?
> >
> > >> Mocks and stubs are the same, except that you can put an expectation
> on a
> > >> mock.
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[naraga]

then i think it is too oversimplified. stubs in rhino are optimized to
behave as closely as possible to real objects that are being faked.
this means that stubs maintain state for properties for example
(PropertyBehaviour).

On Oct 20, 5:20 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> I'm familiar with the fowler article and mocking in general...I'm talking in
> terms of Rhino
>
> On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <[EMAIL PROTECTED]
>
> > wrote:
> > I'd recommend you start here...
>
> >http://martinfowler.com/articles/mocksArentStubs.html
>
> > On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
> >> Am working on a code camp presentation and am trying to distill the
> >> subject of mocking with Rhino down to the easiest possible concepts I can
> >> think of.
>
> >> Would you say the following statement is true or false?
>
> >> Mocks and stubs are the same, except that you can put an expectation on a
> >> mock.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

The problem with this article is it is probably framed in the context of
TypeMock, a completely different solution than Rhino.

The question still standsit should be simple...in terms of RhinoMocks
are mocks and stubs the same except for expectations.

On Mon, Oct 20, 2008 at 9:04 AM, naraga <[EMAIL PROTECTED]> wrote:

>
> here's another discussion on this topic:
>
> http://weblogs.asp.net/rosherove/archive/2007/09/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.aspx
>
>
> On Oct 20, 2:09 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> > Am working on a code camp presentation and am trying to distill the
> subject
> > of mocking with Rhino down to the easiest possible concepts I can think
> of.
> >
> > Would you say the following statement is true or false?
> >
> > Mocks and stubs are the same, except that you can put an expectation on a
> > mock.
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Tim Barcz]

I'm familiar with the fowler article and mocking in general...I'm talking in
terms of Rhino

On Mon, Oct 20, 2008 at 8:50 AM, Shane Courtrille <[EMAIL PROTECTED]
> wrote:

> I'd recommend you start here...
>
> http://martinfowler.com/articles/mocksArentStubs.html
>
>
> On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:
>
>> Am working on a code camp presentation and am trying to distill the
>> subject of mocking with Rhino down to the easiest possible concepts I can
>> think of.
>>
>> Would you say the following statement is true or false?
>>
>> Mocks and stubs are the same, except that you can put an expectation on a
>> mock.
>>
>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[naraga]

here's another discussion on this topic:
http://weblogs.asp.net/rosherove/archive/2007/09/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.aspx


On Oct 20, 2:09 pm, "Tim Barcz" <[EMAIL PROTECTED]> wrote:
> Am working on a code camp presentation and am trying to distill the subject
> of mocking with Rhino down to the easiest possible concepts I can think of.
>
> Would you say the following statement is true or false?
>
> Mocks and stubs are the same, except that you can put an expectation on a
> mock.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---

[RhinoMocks] Re: Mocks vs. Stubs

[Shane Courtrille]

I'd recommend you start here...

http://martinfowler.com/articles/mocksArentStubs.html

On Mon, Oct 20, 2008 at 6:09 AM, Tim Barcz <[EMAIL PROTECTED]> wrote:

> Am working on a code camp presentation and am trying to distill the subject
> of mocking with Rhino down to the easiest possible concepts I can think of.
>
> Would you say the following statement is true or false?
>
> Mocks and stubs are the same, except that you can put an expectation on a
> mock.
>
>
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/RhinoMocks?hl=en
-~--~~~~--~~--~--~---