Fakes and Mocks and Stubs, Oh My !!!

So we covered how to use EasyMock to write tests in one of the previous posts, but Mocking is not the only option when you want to test something that depends on a slow and expensive service. Mocking allows you to expect calls and return values when a call is made, and make sure the number of calls were correct and the order, but sometimes, you want a bit more, or not even that much. So in those cases, you have the options of using Stubs or Fakes. So without further delay, your options are :

1. Mocks :
   Well, Mocks... What can I say. I have already ranted and raved about the awesomeness that is Mocks. Mocks and Mocking frameworks allow you to replace heavy and expensive services with Mocks, with which you can set expectations on what calls are made to the service, and return values. This gives you the advantage of knowing exactly what is called and returned, and makes your test deterministic and super fast. You can even set expectations on the number of calls and the order, though this is something that is not extremely recommended, since that makes the test dependent on the implementation, which is never a good thing.
   
   Advantages :
   • Fast, Reliable
   • Deterministic
   • Lightweight
   • Control over expectations and return values.
   
   Disadavantages :
   • Can become dependent on implementation of method being tested.
   • Can become a mockery if not careful, that is, can be testing interaction between mocks and nothing of the actual code. Especially when all that the method under test is doing is delegating to a bunch of service calls.
   • Can involve complicated setup for expectations, especially with unwieldy objects
     
     
2. Stubs :
   Now, whereas with Mocks, you can specify what calls will be received and what will be returned making them somewhat intelligent, Stubs are at the other end of the spectrum. The dumbest of the dumb, the easiest of the easiest, these just stub out the methods of your expensive and heavy class. So a null Stub could return null for each method, or just return some constant value each time it is called. That means that regardless of what the method is called with, it returns the exact same thing, day in and day out. It doesn't adjust, it doesn't react, just returns. Of course, this means that you might not be able to test all the cases you want to inspect / test. But its simple, its easy, and of course, its fast.
   
   Advantages :
   • Fast, reliable
   • Simple
   • Consistent
   
   Disadvantages :
   • Dumb
   • Can't exercise different cases without different stubs
   • Returns only one value consistently
     
     
3. Fakes :
   And finally, we come to the smartest (figuratively) of the lot. The Fakes. For once, being a fake can be good. While Stubs return the same thing again and again, and mocks return what you tell it to, Fakes are smarter. The easiest way to explain a Fake is with an example. Say your code depends on a heavy service like a Database. A FakeDatabase would be an in-memory implementation of the DB, thus making it faster while at the same time, providing the same logic as the normal DB would. There are different types of Fakes, like a listening / recording Fake which records all the values passed to it.
   
   Advantages :
   • Can test while preserving behavior of dependencies
   • Faster than using actual services
   • Can test complicated logic
   • Most comprehensive testing approach
   
   Disadvantages :
   • Can be complicated to set up
   • Not as fast as mocks / stubs
   • Not as easy to define expectations
   • When / Where do you test the fake (especially the complicated ones) ?
   
   

Thats my 2 cents on the different approaches to testing with dependencies. Now that we know what we can do with those darn heavy dependencies, I'll talk more on how to make sure you can use these different approaches to test your code soon.