VSoftTechnologies/Delphi-Mocks

Add TStub that is simpler and doesn't do anything

Closed this issue · 8 comments

Current testing wisdom says that there are two kinds of fakes, Mocks and Stubs. It's probably too late to change this project's name to "Delphi Isolation Framework", but may I suggest that we add a TStub to the project?

TStub would stand in for any class or interface and basically do nothing but "be" the class or interface that it is designed for.

This would enable the framework to be clearer about the purpose of a given fake inside of a test.

Thoughts?

I'm not sure a separate TStub is needed. As I understand it, the difference between a Stub and a Mock is that for Stubs you do not set expectations for it or verify that those expectations were met. So surely you can just use TMock and use just the behavior part?

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

Vince -

I'm working on my book, and the distinction that I'm drawing is that a stub
can never fail a test and a mock should be used to fail a test if the
code is wrong.

It's hard to draw the distinction when you need to use TMock for both a
mock and a stub. I think there is enough of a distinction between the two
-- or at least I think that developers should understand the distinction --
that they merit their own distinct structures.

It's hard to describe the difference between a stub and a mock when all you
have is a mock. ;-)

Nick

On Sat, Sep 7, 2013 at 8:23 PM, Vincent Parrett notifications@github.comwrote:

I'm not sure a separate TStub is needed. As I understand it, the
difference between a Stub and a Mock is that for Stubs you do not set
expectations for it or verify that those expectations were met. So surely
you can just use TMock and use just the behavior part?

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


Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-24012497
.

BTW, Fowler's article makes my point: Mocks aren't stubs, and so we
shouldn't use a mock capable structure to be a stub.

Nick

On Sat, Sep 7, 2013 at 8:23 PM, Vincent Parrett notifications@github.comwrote:

I'm not sure a separate TStub is needed. As I understand it, the
difference between a Stub and a Mock is that for Stubs you do not set
expectations for it or verify that those expectations were met. So surely
you can just use TMock and use just the behavior part?

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


Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-24012497
.

I spent the last hour looking at this, simple enough to create a TStub that leaves out the expectation/verification part of the mock, but at the moment there is no code to deal with providing default return values.. so if you have not setup the stub method then it will raise an exception. If we can find an easy way to provide default return values then I guess we could remove the exception when the return type is simple (string, ordinal etc). Jason was also looking at auto mocking interface/object properties.. will discuss with him on Monday, not sure if he made any progress on this.

Okay, cool -- Sounds interesting.

Thanks for the consideration --

Nick

On Sat, Sep 7, 2013 at 9:40 PM, Vincent Parrett notifications@github.comwrote:

I spent the last hour looking at this, simple enough to create a TStub
that leaves out the expectation/verification part of the mock, but at the
moment there is no code to deal with providing default return values.. so
if you have not setup the stub method then it will raise an exception. If
we can find an easy way to provide default return values then I guess we
could remove the exception when the return type is simple (string, ordinal
etc). Jason was also looking at auto mocking interface/object properties..
will discuss with him on Monday, not sure if he made any progress on this.


Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-24013297
.

I have just pushed a new branch, with TStub. I will merge it into master this week.. but need to first find a better way to get a default TValue for a TRttiType. At compile time, we can use Default(X), but there doesn't seem to be an equivelent runtime method. Usually the compiler magic functions are in System.pas so we could see how they work, but this one isn't.

Hey Nick, found this very nice explanation of the differences between stubs and mocks : http://marknic.net/2010/01/11/mocks-vs-stubs/

sums it up quite nicely.

closing, basic stub support merged in a while back.