Mocking isn't commonly used in Smalltalk testing. In one of my courses I introduce SmallMock and get the students to play with it. My feeling is that mocking breaks encapsulation and makes the testcases specify assumptions which they shouldn't make. This makes the tests too brittle. A small change in the code may force you to change a number of tests to change your assumptions.
I also find that testing with mocks may give tests that pass when the real objects fail. Mocks assume they know how the real objects work. If the real objects work differently than the assumptions then the tests pass even though the real objects fail. This gives the tests some dangerous false positives.
I'd rather use stubs or real objects if possible. I generally find mocks too difficult to work with in unit testing.
Sent from my BlackBerry device on the Rogers Wireless Network
On May 26, 2011, at 5:43 AM, Steffen Märcker wrote:
> I am curious which frameworks exist to mock objects in unit tests. A quick
> search has led me to SmallMock, but what do you use? And why?
> Regards, Steffen
> vwnc mailing list
> [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
I can recommend "sMock" which is in the Cincom Public SToRE Repository.
Yes, mocks seem to be not very popular among Smalltalkers. But I believe that's wrong. :)
I have been using this technique for several years in Smalltalk and I think I can affirm that it helps me to make TDD more consistent and "seamless" leading to a more modular and (if properly applied) clear design. Of course, mock tests must be combined with "classic" ones as they naturally complement each other at different steps of development.
Concerning tools for mocking, I use and highly recommend Mocketry (available for VW and Pharo/Squeak). Unlike SMocks, Mocketry allows to write expectations (very naturally) as message sends and provides a bunch of interesting and useful features for mocking and specifications. For example, famous Fowler's "Warehouse" example can be written as follows:
OrderFillingTests >> testDoesNotRemoveInventoryIfNotEnoughInStock | order | order := Order on: 101 of: #article. [:warehouse | [order fillIn: warehouse] should strictly
satisfy: [(warehouse has: 101 of: #article) willReturn: false]] runScenario. self deny: order isFilled
The warehouse parameter here is automatically initialized with a mock object. Sending #fillIn: to an order we expect the warehouse (we provided as parameter there) to be asked if it has the needed inventory. Here, we want it to answer "no" (prohibiting the order to be filled).
BTW, I am currently working on articles covering my experience with mocks and Mocketry, one of which I'd like to present at ESUG 2011 (if accepted of course, and able to afford necessary means to come there).
On Friday, May 27, 2011, Sudhakar Krishnamachari
<[hidden email]> wrote:
> Mocks are essentiall specially for legacy code / apps that are having interfaces built with dependency on external DB connection , socket connections, file handling etc which may cause:
> * Slow down Unit tests
> * make it impossible to setup - teardown prereqs..
> As in one of of apps I am working with.. there are really no pure value models.. but model classes which are all consuming in their purpose and link to ORM for saving, cache and do whole lot of stuff if you even call a #new to the class.. hacked through on setters to go backwards and validate through umpteen other model attributes etc..
> In such situations Mock is of value..
> The cons as is enumerated is... that Mocks can easily lead up the rosy path of wasted effort and will need a comprehensive effort in architecting and maintaining the tests relevant to the codebase..
> Unless the whole team are real agilers and understand the gestalt of UnitTesting to the core Mocks can become a grand failure in just 6 -12 months of use...
> On Fri, May 27, 2011 at 8:03 AM, Dennis Schetinin <[hidden email]> wrote: