2011/5/31 Göran Krampe <goran@krampe.se>:
On 05/31/2011 04:59 PM, Frank Shearar wrote:
2011/5/31 Göran Krampe<goran@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