I went back and re-read the article to make sure I was not missing something and really all this article does is compare the state-based vs. interaction methods of testing and building applications. In the end, bascially he tosses the decision on which one is better back to the reader. I can see both sides of this, but to me, the following quote is the reason I see a true benefit to mock objects rather than skipping unit testing and going straight to integration testing ... "If you introduce a bug to a system with interaction testing, it will usually cause only tests whose primary object contains the bug to fail. With a state-based approach, however, any tests of client objects can also fail, which leads to failures where the buggy object is used as a secondary object. As a result a failure in a highly used object causes a ripple of failing tests all across the system."
I would much rather know exactly where an issue occurs rather than having a dozen different tests fail, all with potentially different errors, and now I have to trace through all of those tests to figure out if one bug caused all of the issues or if there is a bigger problem. Unit testing does not replace integration testing, but I want to make sure all of the individual units are tested and working before I start testing them in groups. So, in answer to your question, yes, I believe mock objects are what I am looking for. Thanks ---------------------------------------- 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 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]
