Pintside Thoughts
SMock Introduction

SMock is a Mock Object implementation for Dolphin Smalltalk. From my co-authored paper, "Mock Roles, Not Objects", mocks are:

"a technique for identifying types in a system based on the roles that objects play. In [9] we introduced the concept of Mock Objects as a technique to support Test-Driven Development. We stated that it encouraged better structured tests and, more importantly, improved domain code by preserving encapsulation, reducing dependencies and clarifying the interactions between classes. ...
we have refined and adjusted the technique based on our experience since then. In particular, we now understand that the most important benefit of Mock Objects is what we originally called interface discovery”.

This Smalltalk implementation incorporates several features that make writing tests in Dolphin both fun and productive:

  1. Clear readable syntax for easily creating Mocks
  2. Contraints to specify keyword parameters, and create clear error messages
  3. Optional SUnitBrowser improvments to easily run tests by keyboard shortcut and view error messages in the browser statusbar
  4. Ability to use Mock definitions to generate code
All of these features can be seen in the Flash demo, Mock Objects and TDD in action.

SMock Download

The initial version is available as: SMock.zip

Contents:

SMock.pac Main SMock Library
SMock Examples.pac A Simple example (incomplete)
Constraints.pac Prerequisite - Constraints for specifying And, Or, KindOf etc.

Items in bold are main packages that should be loaded into Dolphin (the others are pre-requisites).

To obtain the SUnitBrowser enhancements, refer to Dolphin Tools.

Currently documentation is limited to what is described in the flash demo. 

SMock Background

After many years of programming in Java and C#, I decided to revisit Smalltalk after hearing about the new Dolphin Smalltalk X6 (with its cool features like tabbed browsing and code completion). I've been very impressed, having a modern IDE (especially when you are used to Eclipse or IntelliJ) makes doing the right things just that little bit easier.

However, when I started writing a little application, I discovered that I really missed using tests to discover the interfaces (protocols) between objects that I was creating. While Smalltalk is a dynamically typed language, the notion of protocol is still important, and I find that I enjoy using Test Driven Development (TDD) to explore object dependencies and responsibilities.

So, I put my problem on hold and quickly whipped up a simple Mock Object library for Dolphin. It was a simple class that used a Dictionary and #doesNotUnderstand: to allow me to specify methods for objects that I hadn't yet created. This was fine for the first few tests, but I quickly found that my tests weren't failing as cleanly as I wanted them to. Sometimes the errors were hidden in a long walkback and I had to debug my tests to find out what went wrong. This didn't feel right, especially as in Java and C# I was used to getting much better feedback from the Mock libraries I have collaborated on. So I rolled up my sleeves, and checked with my colleagues who helped me write the original Mock Object papers, and we created an example of what a good test could look like. From this example I then began morphing my simple class into something that could help me write such tests. I have called the result, SMock (to align with its cousins, JMock and NMock).

Mock Objects History

While working at Connextra in late 1999, several of us discussed testing strategies at what was then called the London Architecture group. At that meeting I vividly recall grappling with ways to test, untestable things. We explored pragmatic approaches that we were taking to make testing easier - introducing getters, using package protection (in Java) etc. My bosses at the time (John Nolan and Peter Marks) were adament that we shouldn't break our designs in this way, John more forcefully said: I want No Getters in our code! From this remark we discussed the "onion peel" layers of software, and how to test between layers... loose ideas emerged concerning interfaces that were to crystalize several days later in the Connextra office.

From those early conversations, I began working in the development team to test in a different way. We removed our getters, and left with few alternatives, we concentrated on what the interfaces could do. We started creating stubs that we injected into the code. Of course this worked, however we wanted our tests to fail better, and from this thought I began to spot a pattern of repeated test code, which I called Expectations. These were refactored into ExpectionList, ExpectationSet, ExpectionCounter etc. Slowly a pattern began to form, and we named this approach "Mock Objects".

Alongside these discoveries, I had started the eXtreme Tuesday Club with Oli Bye, and at these meetings I began talking about what we were doing at Connextra. I remember telling everyone (in reference to Mocks), "This is such a simple idea, I'm sure its not very interesting as everyone must use something similar". It was my colleague, Steve Freeman who pointed out that simple ideas are often the best, and that the simple idea wasn't so obvious to everyone. He offered to work with me to write up the experience, and so along with another XtC regular (Philip Craig - who went on to create N-Unit) we began meeting up to explore and write about the details.

Years later, Mock objects are still quite controversial, often misused and sometimes misunderstood. I think our first paper, Endotesting With Mock Objects assumed that people would understand much more readily than they did. To improve the situation, we collaborated with several other colleagues to write a much clearer description in Mock Roles, Not Objects.