Check out and contribute to CodePedia, the wiki for developers.
*/
*/

An Introduction to Mock Objects

Theme Graphic
Theme Graphic

The Official Programmer's Heaven Blog

The blog where the Programmer's Heaven team post stuff.

Subscribe

Author

Often knowledgable, sometimes wise, occasionally funny. The Programmer's Heaven blog team post about a whole range of topics, from practical advice on concurrency control to introductions to lesser known concepts such as functional programming. Don't forget to comment on the posts and let them know what you think, like and hate!

Archive

Tags

Posted on Tuesday, April 15, 2008 at 2:26 PM

An Introduction to Mock Objects

Writing automated tests is a tried and tested way to improve the quality of software. In the initial phase of development, tests help to verify that the code functions correctly. In Test Driven Development, tests are written before the code, so any knowledge about the ins and outs of the implementation won't influence the writing of the tests. After the initial development, as changes are made over time, a comprehensive test suite can quickly point out unintended changes in the behavior of the code, so the bugs can be fixed before the software is shipped. Importantly, the tests are automated, so they are very cheap to run in terms of time.

What do we want from a test suite?

There are a range of properties that are good to have in a test suite.
  • It often allows bugs to be pinpointed to a relatively small area of the code base, saving debugging time.
  • It should run quickly enough to make running the suite feel like something developers can afford to do regularly. I've worked on projects where the test suite could take a very long time to run, and the consequence was inevitable: people didn't always run the tests before committing changes. I'm at least as guilty as anyone else on the project for doing this, especially when hacking on my slow old laptop.
  • It tests not only individual bits of the software, but also tests them running in combination.
This last point is important. We want to be able to test relatively small units of code in isolation, giving us the ability to pinpoint the problems. However, we also need integration tests. Sure, two classes might work fine on their own and pass their tests, but what happens when you start using them in combination?

The tests for small units of the code are easy enough to write for some things. For example, the tests for the data access layer may not depend on any other bits of the code. However, the class that uses the data access layer to pull data from the database and do a series of complex calculations based on it is harder to test in isolation.

Testing it in combination with the data access layer doesn't tell us right away where the bug lies if a wrong result comes out: in the data access layer, the data in the database or in the calculation code. Moreover, database queries take time, and slow down the running of our tests. And if we want to test the calculations with some edge cases, we have to go and add them to the database, or write code to do so. This is a simple example, but as you build complex software with complex dependencies, it gets more and more important to try and test individual pieces of the software both in isolation and rapidly.

Introducing Mock Objects

A mock object is one that has the same interface (that is, the same properties and methods) as some real object, but unlike the real object just returns dummy data. It will also validate the data that we pass it as arguments, simulating failure when these arguments would have led to a failure.

When we run tests for a class that would normally use the real object, we can instead supply it with the mock object. This allows us a new level of flexibility in our testing.
  • We can modify the mock object during the tests to get it to get it to return a range of different data - valid, invalid, edge cases and so forth - to test how the code calling it handles such situations.
  • We can have the mock object simulate failures, such as an inability to connect to a database, to test the failure mode of the code using in.
  • We can log exactly what the code using the mock object did (e.g. what methods it called, and with what parameters), which may aid the debugging process.
Additionally, because the mock object is not really doing a great deal of work, but instead is just returning data, our tests may be able to run much more quickly.

Imagine we made a mock object for our data access layer. Since it didn't really have to go off to the database to fetch the data or do the updates, the tests would be a lot faster to run. Additionally, we could return a range of different data and test how the code doing the calculations responds without having to actually modify the database itself. We can also simulate database failure without taking down the database!

Mocking Your Language

Writing your own classes for mock objects would be tedious. Thankfully, a range of mocking frameworks exist, which help take the boring work out of creating mock objects for you by allowing you to specify the mock objects more declaratively. In a future article, I'll take a look at NMock, a mocking framework for .Net. In the meantime, here are some mock object frameworks for different platforms and languages. Happy mocking!

0 comments on "An Introduction to Mock Objects"
No comments posted yet.

Leave A Comment
Subject:


Comment:
   Bold Italic Underline          Code Link Image Horizontal Rule


Because you do not have or are not logged in to your Programmer's Heaven account, please enter your name.

Name:


To help prevent comment SPAM, please enter the magic code '211' in the box:




Posting Rules
Please follow these rules when posting comments on blog posts.
  • Do not post anything that is racist, hate speech or of a sexual or adult nature.
  • Do not post or link to anything that infringes copyrighted laws.
  • Posting about security or legal topics is fine so long as you are not glorifying or encouraging people to perform illegal activities.
  • Both the author of this blog and the Programmer's Heaven administrators may delete any inappropriate comments without notice at their own discretion.

corner
© 1996-2008 CommunityHeaven LLC. All rights reserved. Reproduction in whole or in part, in any form or medium without express written permission is prohibited.
Violators of this policy may be subject to legal action. Please read our Terms Of Use and Privacy Statement for more information.
North American business development: Nicolai Wadstrom. Publisher: Lars Hagelin.
Resource Listings