[Esug-list] Proposal for Mock Objects at ESUG 2011

Frank Shearar frank.shearar at gmail.com
Tue May 31 10:59:33 EDT 2011


2011/5/31 Göran Krampe <goran at krampe.se>:
> Hey!
>
> Stumbled into this thread but just HAVE to respond... Snipping heavily here:
>
> On 05/27/2011 11:11 PM, Colin Putney wrote:
>>
>> without them. It's just *mocks* that are mostly unnecessary.
>
> Amen! I have been thinking the rest of the world had gone mad...
>
>> Personally, I find that mocks are *very* useful in a few very specific
>> situations, but they can cause problems it other situations. They're
>> like a very specialized tool - invaluable when you need it, but kept
>> in the bottom of the toolbox and not used very often.
>
> Right.
>
> [SNIP of good stuff]
>>
>> I know that BDD folks like to talk about testing behaviour rather than
>> state, but I don't find the distinction useful. Testing state breaks
>> the encapsulation of the objects under test, and couples the test too
>> closely to their internal implementation. Testing behaviour using
>> mocks *does the same thing*; it just restricts the implementation in a
>> different way.
>
> So refreshingly to see someone that *also* notes that testing using mocks
> actually break encapsulation. Thank you, thank you...

Or to rephrase, "documenting the precise nature of the colloboration
between an object and its context documents that precise nature."

In Colin's example, Set's collaboration with Array is purely an
implementation detail and, as he notes, testing the implementation -
whether checking that Set stores the value in the array, or what
messages Set might send to Array - hurts you.

I fail to see how that makes mocks bad. Unless you're railing against
hype? In which case, I agree: there ain't no such thing as a free
lunch, there is no silver bullet, etc etc.

frank




More information about the Esug-list mailing list