Fwd: Fowler on Mocks

markus sent me this nice article on mocks...


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

stéphane ducasse a écrit :
> markus sent me this nice article on mocks...
>
>
>> http://www.martinfowler.com/articles/mocksArentStubs.html
>
>
>


Thank intresting!

Do we have a way to define mock in Squeak?

Math

On Tuesday 08 August 2006 18:02, Mathieu wrote:
I recall something on the list about a Teachable class which I suspect could get us most of the way.

Brent

Dave Astels, sSpec will include a Mock object implementation (but its
not squeak yet as far as I know)

Keith

               
___________________________________________________________
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

There is a package somewhere with teachable objects indeed. I'm  
interested to get my hands on it :)

Stef

On 8 août 06, at 18:27, Brent Pinkney wrote:

I have a teachable object as part of my MOF implementation, it´s in  
VW but maybe you can reuse.

Adrian

On Aug 8, 2006, at 11:18 PM, stéphane ducasse wrote:

I think that Omnibrowser does use of Mock objects for testing.

Regards,
Hernán




--
Saludos,
Hernán

Out of curiosity I had a go at the basics of such a utility. It was easy to get simple cases working with just a handful of methods.

| mockObject |
mockObject := MockObject new.
mockObject answer: [mockObject square: 5] with: 25.
mockObject square: 5     " 25 "

I've attached what I ended up with which could easily be extended to return multiple, one off or random values.

Z.
<a href="cid:part1.07000009.03090408@orange.net">
Mathieu wrote:

stéphane ducasse a écrit :
  

markus sent me this nice article on mocks...


    

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

Thank intresting!

Do we have a way to define mock in Squeak?

Math






  

'From Squeak3.9alpha of 4 July 2005 [latest update: #7048] on 8 August 2006 at 10:23:37 pm'!

!Message methodsFor: '*mock' stamp: 'ZA 8/8/2006 21:49'!
hash
        ^ selector hash! !

'From Squeak3.9alpha of 4 July 2005 [latest update: #7048] on 8 August 2006 at 10:22:52 pm'!
Object subclass: #MockObject
        instanceVariableNames: 'answers answerWithMockAnswer'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Mock-Prototype'!
!MockObject commentStamp: 'ZA 8/8/2006 22:10' prior: 0!
I am a mock object who can be instructed to answer specific messages with predefined mock answers.!


!MockObject methodsFor: 'initialize-release' stamp: 'ZA 8/8/2006 21:19'!
initialize
        super initialize.
        answers := Dictionary new! !


!MockObject methodsFor: 'mock' stamp: 'ZA 8/8/2006 22:14'!
answer: aBlock with: anObject
        self answerWithMockAnswer.
        (aBlock value) value: anObject.
        self answerWithMockAnswerValue.
! !

!MockObject methodsFor: 'mock' stamp: 'ZA 8/8/2006 21:32'!
answerWithMockAnswer.
        answerWithMockAnswer := true
! !

!MockObject methodsFor: 'mock' stamp: 'ZA 8/8/2006 21:33'!
answerWithMockAnswerValue
        answerWithMockAnswer := false
! !

!MockObject methodsFor: 'mock' stamp: 'ZA 8/8/2006 21:58'!
doesNotUnderstand: aMessage
        ^ answerWithMockAnswer
                ifTrue: [answers
                                at: aMessage
                                ifAbsentPut: [MockAnswer new]]
                ifFalse: [(answers includesKey: aMessage)
                                ifTrue: [(answers at: aMessage) value]
                                ifFalse: [super doesNotUnderstand: aMessage]]! !

'From Squeak3.9alpha of 4 July 2005 [latest update: #7048] on 8 August 2006 at 10:23:12 pm'!

!Message methodsFor: '*mock' stamp: 'ZA 8/8/2006 21:43'!
= anObject
        ^ (anObject isKindOf: self class)
                and: [selector = anObject selector & (args = anObject arguments) & (lookupClass = anObject lookupClass)]! !

'From Squeak3.9alpha of 4 July 2005 [latest update: #7048] on 8 August 2006 at 10:23:37 pm'!

!Message methodsFor: '*mock' stamp: 'ZA 8/8/2006 21:49'!
hash
        ^ selector hash! !

'From Squeak3.9alpha of 4 July 2005 [latest update: #7048] on 8 August 2006 at 10:22:59 pm'!
Object subclass: #MockAnswer
        instanceVariableNames: 'value'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Mock-Prototype'!
!MockAnswer commentStamp: 'ZA 8/8/2006 22:11' prior: 0!
I am a mock answer whose value should be returned in response to a predefined message. I could be much more than a simple value holder if given the chance. I should only ever be dealt with by MockObject, don't let me out on my own, I'll only embarras you.!


!MockAnswer methodsFor: 'accessing' stamp: 'ZA 8/8/2006 21:09'!
value
        ^ value! !

!MockAnswer methodsFor: 'accessing' stamp: 'ZA 8/8/2006 21:09'!
value: anObject
        value := anObject! !


!MockAnswer methodsFor: 'printing' stamp: 'ZA 8/8/2006 22:12'!
printOn: aWriteStream
        ^ value printOn: aWriteStream! !

This should help you Stéphane...

http://www.squeaksource.com/Teachable/


stéphane ducasse wrote:

On Aug 8, 2006, at 11:31 PM, Zulq Alam wrote:

> This should help you Stéphane...
>
> http://www.squeaksource.com/Teachable/

...but note that these teachables help us to build stubs  and not  
_mocks.

Fine for me: Whereas I can see the value of stubs for stubbing  
external systems (like web-pages as described above) I stick like  
Fowler with the state-based testers.
Don't know why I would want to ensure that some specific methods are  
called during my code, I prefer to check the result.

As for the example used in the Oopsla paper of the mock Proponents (a  
cache - the mocks ensure that objects are not fetched again from the  
outside if already present (blurring the difference between mocks and  
stubs again of course)) I prefer to test if I get the right result  
within a certain time, both possible without mocks.
http://www.jmock.org/oopsla2004.pdf

If I later decide that I can get rid of the caching and always fetch  
the data from outside, I can reuse my state-based test whereas I  
would have to throw away the mocks.
As Fowler says I "am concerned about the consequences of coupling  
tests to implementation."

And aren't we taught to write method names which reflect the "what"  
and not the "how"?

Cheers,

Markus

On Aug 8, 2006, at 5:23 PM, Hernan Tylim wrote:

> I think that Omnibrowser does use of Mock objects for testing.

OB-Tests-Core does have a class called OBProtocolMock that I was  
using for a while, but some recent refactoring removed all the tests  
that were using it. OBProtocolMockTest is a pretty good documentation  
on how to use it, for those who are interested.

In general though, I agree with Markus, Martin Fowler and others that  
excessive use of mocks leads to fragile tests. A few years ago,  
OmniBrowser had an extensive set of "behavior tests" involving lots  
of mocks. Then I made a small design change that completely broke all  
those tests. Dozens of them. I ended up just throwing away the tests  
and leaving parts of OB untested. Recently I've been rewriting those  
parts anyway, and slowly they're getting covered with tests again,  
this time without mocks.

These days, I find I use mocks very, very infrequently.  
OBProtocolMock was written for a fairly unique situation, where the  
functionality I was testing was a message dispatcher. It's job was to  
receive messages and forward them on to other objects according to  
certain policies. I used the protocol mock to verify that the right  
messages were being forwarded correctly.

Another area where I find that mocks are really handy is in testing  
input/output. I once implemented a MockWriteStream in VW that was  
very handy for testing code that wrote out data in specific file  
formats. For example, might write a test like this for an html  
serializer:

document := HtmlDocument title: 'Example'.
stream := MockWriteStream on: '<html><head><title>Example</title></
head></html>'.
document writeOn: stream.

If the document wrote everything out as expected, the test passed. If  
it wrote something incorrectly the mock stream would throw a  
TestFailure exception. It was great for debugging, because you could  
see exactly which code was writing the wrong thing.

In Squeak I once wrote a Mocket class which did the same sort of  
thing for sockets. Mocks are especially handy when testing network  
protocol implementations because they let you get around the  
threading issues that come up when testing real clients and servers  
together.

On the whole, I find mocks are very useful when the functionality I  
want to test is communication in some form or another. Most of the  
time, though, I don't care what messages are sent, since the result  
I'm after is usually some kind of state. Further, specifying the  
messages that have to be sent ties my hands when it comes to  
implementation, since messages are all I have to work with.

Colin

Thanks for the information. And yes I'm also concerned with the  
results of too much mock.

Stef

On 9 août 06, at 01:37, Colin Putney wrote:

Thanks stressing that I still have to digest the difference.
I thought that Teachable was a mock state base approach. I should  
have a look.

On 8 août 06, at 23:52, Markus Gaelli wrote:

After looking at it, I can see you are right.

With regards to mocks, the interesting part for me is the ability to
change factors that effect the execution without creating a new class or
writing code to manipulate the stub again and again, i.e. the stub. I
would use these in state based testing as a better stub.

With regard to Teachable, I think my implementation earlier in the
thread is more flexible as it can deal with methods and simple arguments
rather than just selectors (as I understood Teachable).

Markus Gaelli wrote: