Mock Objects



More content will be added to fill this space at some point in the future.

home :: techie :: blog :: programming :: agile :: MockObjects.txt

Mock Objects

I am always surprised how many programmers that I speak to have not heard of Mock Objects. Some can get away with it, they are those that wouldn't know what a unit test was if it bit them on the bum. Those that are writing unit tests have less of an excuse. People at an agile event I attended recently have no excuse at all, but at least they were interested in learning.

Well, lets see if I can explain what they are and why you would want mock objects, before you go and read the entry on the c2 wiki.

When writing code, or testing it you may not want to use the full production version of another class. This may be because you have not implemented the other class yet, but still need to run your code. You can compile ågainst an interface, but you can't test that your code behaves as expected without running it, and it is faster to implement a mock version of the final class than to wait for a full version. The other time you might use mock objects (and the time when I tend to use them) is when you are writing unit tests. You probably don't want to interact with a full-blown database that takes time to set-up, instead you can work with a facade of simple business objects that are more predictable and faster to use. You can also use mock versions of classes to introduce problems, such as thrown exceptions, to test how your class handles them.

There are two types of mock objects. There are the simple static mock objects, and the slightly more complicated dynamic mocks.

Static mock objects are where a programmer has written a class implementing an interface, but doing as little as possible, or maybe adding ways of throwing exceptions and that sort of things. You can download mock implementations of most of j2ee from . This will probably lead to evem more people accusing you of having more tests than code, as you will have extra implementations of all of your interfaces that don't do anything. This can lead to well-implemented mocks, and you can even distribute them (possibly in a different jar), allowing people who use your code as a library, or otherwise use it in their code can use your mocked out versions of your classes. The advantage of static mocks is that they only need the language to support interfaces with multiple interfaces, and can probably be fakes at the link stage for more primative languages.

Dynamic mocks are generated at runtime using techniques such as reflection or emitting dynamic bytecode. Here you programmatically create an object that implements your interface (and some can use funky tricks to create fakes of any object), and tell it how to behave in this situation. This is followed by using this proxy object in the class after which you can ask it if it did what was expected of it. There can be a little more overhead when using dynamic mocks as all of the reflection takes time for methods that are called many times. This isn't overly likely to happen depending on how you write your unit tests but it can.

I suggest that any programmers that are either working on large projects where you have to write code against an interface, or who are writing unit tests, particularly those doing test-driven development, in Java or C# at least. To check out the use of mock objects to make life a little easier.

Last updated: 11:49, 21 Nov 2004 [ /techie/blog/programming/agile ] Link..