On 12/22/06, Paul Kenney <[EMAIL PROTECTED]> wrote:
Whenever I see someone talking about the need for mocks when unit testsing,
this essay by Martin Fowler comes to mind:
http://www.martinfowler.com/articles/mocksArentStubs.html
Read it and then ask yourself if its really mocks you need.
Paul
That's a good article. But I'm not sure it really convinces me that
interaction-base testing is not right for CFML.
Its true, the mock object can be used as a stub. In fact I've used it
as such, simply because I find it easier to create a stub using it,
because I don't have to also create any secondary components (or the
components those rely on,... so on and so forth). I only have to worry
about the primary component's immediate neighbors.
However, even thought the CFUnit mock object is a convenient way to
create stubs, it's also a mock object. The biggest difference between
CFUnit mock object and most of the Java based ones is that there is no
automatic validation on any preset expectations. You tell the mock
object which methods to override, and how to respond when they are
called. CFUnit mock object will then record all calls to those
overridden methods. Afterward you can verify that method A was called
3 times, or that when method B was called and was passed the expected
arguments. Because of this record/playback style I think CFUnit mock
object is most similar to how EasyMock works. But as Martin points
out, one of EasyMocks shortcomings is:
"The downside is that you can't have the looser constraints."
Well, as I often find with CFML, we can have the best of both worlds.
We can be as strict or flexible as we like. This is why I left the
expectation validation up to the user. If you want to validate the
arguments passed to every single call to your mock object you can. Or
if you simply care that a method was called at all, and don't care
what arguments were passed, you can do that too.
Because of the inherent looseness CFML allows, I actually feel that
mock objects are very applicable to ColdFusion. We can actually do
things which are difficult to accomplish in "stricter" languages (like
allowing an overridden function accept any combination of parameters
without having to override it multiple times).
And even though mock objects are often used in TDD, I don't think you
must use TDD to use mock objects. I have made a number of test cases
that use mock objects, where I was not strictly following TDD.
So like anything in CFML, I would say the great thing about mock
objects is,... its there if you want it (I think that should be
ColdFusion's motto). You can use it to simply create stubs, or you can
use it to make some very strict interaction based testing. Personally,
I often mix it up. In cases were state-based testing would work best;
I use them as stubs (or create customer stubs). In cases where I want
to be sure of the interactions happening behind the scenes, or I need
to decouple my test case from an outside source, or I simply want to
avoid involving more then my primary component, I use mock objects.
--
Rob Blackburn
http://www.rbdev.net
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
