views:

271

answers:

4

Is there any place or any one out there who can explain how this works in plain English instead of "defining terms in terms of themselves"?

+1  A: 

A mock is a surrogate that you can instruct to behave in a certain way. This is useful for testing where you want to eliminate a dependency by switching the actual instance with a mock object.

Unlike stubs mocks keep track of actual usage, so your test may verify that the mock was used as expected.

More info in Fowler's article here.

Brian Rasmussen
+4  A: 

So, you have a class that is dependent on something else.

Lets use a metaphor: a car requires an engine.

The car is dependent on the engine. It's easy to test that the car and engine work together, but what about testing the car without an engine, or that the car "calls" the engine correctly. What we could do is put something (a mock) in place of the engine, and press the gas (make a call), and verify that the fake (mock) engine received the correct input to the throttle body. Rather than verifying the whole system, you've just tested the thing you want in isolation by measuring with a mock object.

It gets way more complicated and way more powerful in practice, but...

Rob Rodi
A: 

Here is the Wikipedia entry on it.

cbeuker
+2  A: 

If you write units test for your classes, at some point you'll encounter a situation where your test executes code calling an external resource. Most often this is a database, but others are possible as well. I usually use a creditcard billing service provider as an example because in that situation it becomes obvious you don't want to actually call the service each time you run a test.

In such a situation it is common to replace the service object with a sort of fake service that does not use any resources. This is called a stub or a mock object. The difference between a stub and a mock seems to be the subject of some discussion but in essence they are the same.

Mocking frameworks as Rhino Mock help you create mock objects that respond as you would expect the actual service. You could compare the to recordings made of the actual responses of the service calls that you can replay each time you perform the test.

DefLog