Unit testing with Mock Object

Not only mock object is an important concept in Unit testing, it is also a very good illustration of refactoring (see Refactoring: Improving the Design of Existing Code. see Resources)

Wikepedia( http://en.wikipedia.org/wiki/Mock_object) :  “ In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is impractical or impossible to incorporate into a unit test. If an object has any of the following characteristics, it may be useful to use a mock object in its place:

  • supplies non-deterministic results (e.g. the current time or the current temperature);
  • has states that are difficult to create or reproduce (e.g. a network error);
  • is slow (e.g. a complete database, which would have to be initialized before the test);
  • does not yet exist or may change behavior;
  • would have to include information and methods exclusively for testing purposes (and not for its actual task).          “

The article below is cited from http://www.ibm.com/developerworks/library/j-mocktest/index.html

Unit testing has become widely accepted as a “best practice” for software development. When you write an object, you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.

When you’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators.

Refactoring: Extract and override factory method

A refactoring is a code change that leaves the original functionality intact, but changes the design of the code so that it’s cleaner, more efficient, and easier to test. This section offers a step-by-step description of the Extract and Override factory method refactoring.

Problem: The object being tested creates a collaborator object. This collaborator must be replaced with a mock object.



A refactoring consists of many small, technical steps. Together, these are called the mechanics. If you follow the mechanics closely like a cookbook recipe, you should be able to learn the refactoring without much trouble.

  1. Identify all occurrences of code that create or obtain the collaborator.
  2. Apply the Extract Method refactoring to this creation code, creating the factory method (discussed on page 110 of Fowler’s book; see the Resources section for more information).
  3. Assure that the factory method is accessible to the target object and its subclasses. (in the Java language, use theprotected keyword).
  4. In your test code, create a mock object implementing the same interface as the collaborator.
  5. In your test code, create a specialization object that extends (specializes) the target.
  6. In the specialization object, override the creation method to return a mock object that accommodates your test.
  7. Optional: create a unit test to assure that the original target object’s factory method still returns the correct, non-mock object.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s