Let's say you are a programmer.
Let's say you are aware of the traps a big IT project can fall into, and you decide to adopt a test driven approach.
On the next day, you find out that this huge (900 md) part of the code that is done by this other contractor will not be delivered until 2009, and of course you need this part to test your code...Treat yourself and build a mock object that will simulate the behaviour of the missing part of the code !

Wikipedia says you normally need this (these) mock object because this damn contractor code :

  • produces non-deterministic results like current time or 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); (You don't run a test that is slo 100 times a day...especially if you have 100 tests like this one 8-O )
  • 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).

A proper conception of your mock object will be the following :
Upon a commonly agreed interface with the ... contractor :

  1. he builds his code
  2. you call the interface to interact with his object
  3. you buil a mockup implementing the interface, who will act in the same way as the other guy's code
  4. you deliver !

Ok, but a test class can do the job, why would i want a mockup?
Probably in the cases where you interact with some objects that are complex to mimic (you do not want to build them in messy test cases), when these objects are slow to build, or cost time to calculate (remember a big project usually involves a suite of hundreds of test, and the suite needs to be run fast...), when you need to test states like DB is down, but you do not want to stop the db to run your test ;-)