Esug-list

By thread

esug-list@lists.esug.org

June 2011

17 participants
26 messages

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

by Frank Shearar

2011/5/31 Göran Krampe <goran(a)krampe.se>: > On 05/31/2011 04:59 PM, Frank Shearar wrote: >> >> 2011/5/31 Göran Krampe<goran(a)krampe.se>: >>> >>> 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. > > Well, yes, railing against hype. But also railing against writing tests that > work from "the inside" by using mocks. It is of course a matter of taste, > style and in the end weighing pros and cons. But I have seen too much use of > mocks that end up making the tests purely mirror the implementation - so > even the slightest internal modification would break the test. PragProg were kind enough to publish a very well-timed article: http://pragprog.com/magazines/2011-06/practical-mock-advice The punchline? "Generally, there is one overarching reason for why you would use a mock. That reason is this: You care about an implementation detail in your code. And when do you care? You care when it drives behavior." frank

June 1, 2011