The primary objective with this session was to answer some fundamental questions regarding mock objects within a unit testing process. I would like to personally thank Warren Oliver and Chris Stevenson from ThoughtWorks?, Inc., and Amr Elssamadisy from Valtech Technologies, Inc. for providing great and useful information on this subject.
Here are the questions and answers that were given during this session. You will find a list of external useful links to get more information on this subject.
What is a mock object?
- You can view the existence of a mock object as an impersonator of another concrete class. It impersonates a class by allowing you to test an object via its interface definition, instead of its concrete implementation.
- There is a difference between a stub and a mock object. In short, a stub doesn’t expect anything to occur, whereas a mock object is expecting something to occur.
Why and when should we mock an object?
- A common scenario could be that you have to test an object that is located in a different domain boundary, i.e., you want to test an object in a different layer or in a remote environment.
- Another reason could be that there is some uncertainty regarding the state or the behavior of an object under test. For instance, you want to test using an object whose service is temporarily unavailable, inconsistent, variable, unique, etc. An example would be to test an object that performs some special operation only if the date is a February 29 (therefore every four years...you don't have time to wait that long to test it!).
How do we mock an object?
- There are several existing object mocking tools available for various development frameworks (.NET, Java, etc.)
- You can also find some very useful tutorials on testing with mock objects (see the ‘Useful links’ section)
Who should perform testing with mock objects?
- The person coding behind the screen ;)
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Useful links
Tutorials and resources
- A Mock Object definition by Wikipedia (http://en.wikipedia.org/wiki/Mock_object)
- “Mocks Aren’t Stubs”, an article by Martin Fowler (http://www.martinfowler.com/articles/mocksArentStubs.html)
- Amr brought up the subject of Object Mother during our conversation. I don’t know much about Object Mother yet, but here’s a link to read more about it (http://www.thoughtworks.com/object-mother-easing-test-object-creation.pdf#search=%22object%20mother%22)
- “Mock Object” is a also a great site to find other useful information on this technique (http://www.mockobjects.com/)
Tools
Easymock (http://www.easymock.org)
EasyMock? provides Mock Objects for interfaces in JUnit tests by generating them on the fly using Java's proxy mechanism. Due to EasyMock?'s unique style of recording expectations, most refactorings will not affect the Mock Objects. So EasyMock? is a perfect fit for Test-Driven Development.
POCMock (http://www.prettyobjects.com)
POCMock is a .NET tool that helps developers to carry out white box automatic testing (which validates what goes on in the code as the developer writes) as opposed to black box testing (which only validates the code’s external effects). This mocking tool also integrates with Visual Studio .NET 2003 and 2005.
JMockIt? (https://jmockit.dev.java.net/)
JMockit consists of a single class with a small set of static methods, which allow arbitrary methods and constructors of any other class to be replaced by mock implementations at runtime.
Doubler (http://jayflowers.com/joomla/index.php?option=com_content&task=view&id=13&Itemid=39)
Doubler is a code generator that makes unit testing easier. It is especially useful when working with legacy code. It is a Reflector add-in, a tool already woven into your workflow. It will help you cleave dependencies apart, create test doubles, and write unit tests with little effort and less coding.
nMock (http://nmock.org/)
NMock is a dynamic mock object library for .NET. Mock objects make it easier to test single components—often single classes—without relying on real implementations of all of the other components. This means we can test just one class, rather than a whole tree of objects, and can pinpoint bugs much more clearly. Mock objects are often used during Test Driven Development.