Progressive Development : mock objects

Motley says: "If-then-else hooks are the best way to inject mock objects"

James Waletzky — Tue, 14 Aug 2007 18:26:00 GMT

Summary

Motley: A simple if-then-else hook is the simplest and best way to inject a mock object.

Maven: First, you have to design to interfaces. Then, techniques like dependency injection, factories, and endo-testing are more effective ways to inject mock objects.

______________________________

[Context: Maven and Motley continue a discussion on mock objects. Maven is just about to show Motley how to design his classes to be mockable]

Motley: As I said, a simple if-then-else hook in my code is probably the best way to inject a mock object for testing. It's simple, which is one of your key design principles, right?

Maven: I'll give you that - it's simple on the outside, but what about maintaining that code into the future? If-then-else hooks all over the place end up looking like spaghetti when you add more over time. Plus, there are other disadvantages.

Motley: First you tell me simple rules, and then you tell me simple leads to spaghetti. You know, Mave, sometimes I want to give you a shot in the-

Maven: Whoa! Stow your temper for a bit, bud. Simplicity, by default, is good. However, there are other slightly m ore elegant solutions that are still simple to follow and maintain. The "if" hooks, although simple to start, lead to complexity. They also require us couple test code to our production code if we inline the "if" statements. Both of those are far from optimal.

Motley: Ok, let's hear about your so-called "elegant" solutions.

Maven: Let's do it! Each require a little bit of object-oriented knowledge, but you're an expert, so no problem.

Motley: Ah, you flatter me. You're also right.

Maven: Above everything else, as we discussed in the past, you need to design to interfaces. Once you have well defined interfaces between your component boundaries, you can plug and play different implementations - mock objects are a great example. But, that's not all. You need to employ a simple technique to invoke the mock objects when required. The first technique is known as "dependency injection."

Motley: Sounds like something a drug addict would do!

Maven: Funny guy. Anyway, let's say we are developing an account class for a bank, and that we are doing some kind of transfer service from one account at our bank to some other remote bank over a secure web service. Perhaps we have code like this:

public class Account

{

public void Transfer(Money amount)

{

remoteBank.Transfer(amount);

}

Pretty straight-forward. Assume that remoteBank talks to a web service somewhere over the wire. We discussed that good unit tests cannot access the network - they have to remain isolated and fast. So, we need to replace the remote bank with something else. We could take your way of putting in an "if" hook, but let's use dependency injection. The remote bank needs a well-defined interface. Assuming that exists, here's what we do:

public class Account

{

public void Transfer(IRemoteBank bank, Money amount)

{

bank.Transfer(amount);

}

Motley: Great. The code basically looks like the same. Are you sniffing something?

Maven: Ah, it may look similar, but it's not the same. A client of the Account class can now pass in an implementation of the remote bank that implements the IRemoteBank interface. That implementation can be a real remote bank (probably by default) or a mock.

Motley: I see some advantages, but jeez, now clients have to know about remote banks, which is arguably an implementation detail of the Account class.

Maven: Very astute, my friend! Definitely a disadvantage mixed in with the advantages. Another technique is to use the factory pattern to return us the right implementation for our needs. Check this out:

public class Account

{

public void Transfer(Money amount)

{

IRemoteBank bank = BankFactory.CreateRemoteBank();

bank.Transfer(amount);

}

public class BankFactory

{

static public IRemoteBank CreateRemoteBank()

{

if (someCondition)

{

return new MockRemoteBank();

}

else

{

return new RemoteBank();

}

The "someCondition" in this case could be a flag or a setting from a configuration file that is true when tests are executing.

Motley: Nice, to some extent. We've now made it such that clients don't need to know anything about implementation detail, but you still have your test code coupled to your core business logic. Ideally we'd like to get rid of that.

Maven: I agree! Factories are nice to separate creation from usage, but they don't solve all our problems. This next technique, called Endo-testing, takes care of some of those disadvantages. Here's the code:

public class Account

{

public void Transfer(Money amount)

{

IRemoteBank bank = this.createRemoteBank();

}

protected virtual IRemoteBank createRemoteBank()

{

return new RemoteBank();

}

Motley: Big deal. So you have an extra helper method to create a new instance of the remote bank object. What does that solve?

Maven: Ah, but notice the virtual on the method declaration. That means that I can subclass the account object, override the createRemoteBank() method on the subclass, and return a mock object for test purposes.

Motley: Oh, um, I was just testing you. You can definitely override that method for test purposes. I guess that has the advantage that our test code is completely decoupled from our product code and clients still don't need to know about the implementation details.

Maven: You bet! There is a disadvantage though-

Motley: Yeah! You can't seal your classes!

Maven: Yes. We have to allow subclassing from our class even though we may not want to. And, we have a "protected" method, which for documentation purposes is essentially public. We really should document it.

Motley: Those seem like small disadvantages though relative to the alternatives. It's a bit more complicated, though, because you have to understand polymorphism, but a good OO developer can deal with that.

______________________________

Maven's Pointer: Know any more good techniques for injecting mock objects? Let us know with a comment below. Of course, all this requires that you design to interfaces, which was one of the main design principles discussed previously.

Maven's Resources:

Working Effectively with Legacy Code, by Michael Feathers, Prentice Hall PTR, ISBN: 0131177052, Sept. 2004.

Motley says: "The only thing I'm going to mock is you"

James Waletzky — Tue, 07 Aug 2007 20:11:00 GMT

Summary

Motley: I can't mock something that I have no control over (like third-party or old legacy code)

Maven: Design to interfaces, create a wrapper, and use tools for mocking. These are all great practices for leveraging mock objects.

______________________________

[Context: Motley is struggling with creating mock objects for his unit tests]

Motley: Arrrrggggghhhh. You know, I'm really trying to do this TDD thing but it is quickly becoming a real pain in the butt. You said that tests have to execute quick. Trust me, I totally believe you on that front. I'm doing my best to make them execute quickly but some things just are not made to mock.

Maven: What's the problem?

Motley: I'm interfacing with Marty's code. I "new" the object up and call it. Unfortunately Marty's stuff takes quite a few seconds to execute. It's making my TDD experience as painful as looking at that shirt you're wearing.

Maven: What's wrong with my shirt? Anyway, the problem is that you are hard coding the instance creation of Marty's object. You are depending on an implementation, which is a violation of one of our key design principles we talked about.

Motley: Yeah, yeah, design to interfaces. But Marty has defined the interface and I have no control over it. No stubbing here, bubba!

Maven: Ah, but you do have some control! The best thing to do would be to collaborate with Marty and get him to expose a well-defined and documented public interface to his component. Then you can simply couple yourself to the interface and not the implementation.

Motley: Right! Then I can plug and play different implementations of the component, replacing Marty's version with my own stub.

Maven: You betcha! You got it, Mot!

Motley: But let's say Marty's component is actually a third party component that I have no control over.

Maven: You can solve any software problem with an extra layer of indirection. I'm kidding of course, but it does help here. In this case, wrap that component with a façade design pattern that provides an interface that you define. Then your core code depends on that façade interface instead of directly on the third party component.

Motley: Ok, fortunately that makes sense. You used the word "mock" previously but it just seems like a stub to me. What is the difference?

Maven: Don't worry too much about the nomenclature. A stub provides some sort of canned response to a call. Usually the response is hard-coded and there is no real logic associated with the result that is returned. A mock is similar to a stub, but it also verifies some kind of behavior. Did the client of the mock call it appropriately? Is the state of the object as we expect? Are return values from methods that we expected to be called set appropriately? The term "mock" goes along with TDD quite frequently, but you can get by effectively just using a stub if you wish.

Motley: So a mock does extra work on top of a stub. How do I get the mock to do this extra work of behavior verification? Do I have to write all the code myself?

Maven: You can, but you can also use a mock object framework. There are a few out on the Internet for various platforms. NMock is an example for .NET, but they're out there for other languages too. Generally the name is xMock, where the "x" is replaced by some kind of letter or phrase corresponding to the language or platform for which it is built.

Motley: I'm still not sold - what about all the wrappers I'll have to write to mock out bits of legacy code that were not designed with interfaces in mind?

Maven: Check out a free tool called TypeMock.NET. TypeMock allows you to mock any class in your system, including concrete classes. No changes are required to the production code. TypeMock automatically intercepts calls to the class(es) of your choosing and injects whatever behavior you specify in its place. It does this in one of two ways: (a) by recording expectations of the code in a similar way that you would record a macro; and (b) using reflection to look for calls to expected methods and replace them with alternatives. The key is running an executable that wraps your test harness such that it is able to hook the desired method calls.

Motley: Holy crap - that sounds incredibly cool!

Maven: About as cool as you are, with all the windows open in the winter.

Motley: Ouch. A dig from Mave. Actually, the only thing you have dug is your grave once we leave the office and I get my hands on you. In all seriousness, I can understand the mock story, but I'm still not sure about the best technique for mocking something out. I figured I would just hack in an "if" statement to give me the right object given the scenario - release or test.

Maven: Good question. A hacked-in hook could work, but it's not the best option. Why don't we go over some methods of injecting mock objects into your design. Let's go write some code on the whiteboard...

______________________________

Maven's Pointer: To take advantage of the full power of mock objects, try a mock object framework like NMock. The Quickstart documentation for NMock contains a simple example of how to use the framework and what is meant by behavior verification.

Maven's Resources:

Mocks Aren't Stubs, by Martin Fowler;
TypeMock.Net
Working Effectively with Legacy Code, by Michael Feathers, Prentice Hall PTR, ISBN: 0131177052, Sept. 2004.

Motley says: "Unit tests take too long to execute, so don't bother"

James Waletzky — Wed, 04 Apr 2007 18:38:00 GMT

Summary

Motley: Unit tests take too long to execute. I'm not going to bother.

Maven: Unit tests need to run quickly - you need to execute them frequently. Mock objects can help.

______________________________

[Context: Motley has been writing unit tests for a couple of days, but is not sold on developers writing test code]

Motley: I've been trying this unit testing thing for a couple of days now but I can't really say I like it. I developed this little executable to run my tests and that took time. You stated that I should run them regularly, but they just take too long to run.

Maven: Whoa - hold on a second. Let's address these things in turn. You're coding using C#, right?

Motley: Yeah. I wouldn't have it any other way.

Maven: Well, it just so happens there are some existing unit test frameworks out there that you should leverage.

Motley: Framework? For what? I just wrote a little executable to run my tests.

Maven: A good C# unit test framework like Visual Studio 2005 or NUnit can do some work for you. They quickly run tests, provide some good visual feedback, tell you the details about any failures, and make it dead simple to write new tests. You definitely need to be using a unit test framework!

Motley: I didn't even know you could do that with Visual Studio - might be worth a try. BUT, these tests just take too long to run so I'm not even sure it's worth the effort.

Maven: There are certain rules of unit testing that you need to follow. First, tests need to run quickly! If they don't run quickly, like in the order of seconds, developers won't run them and they get stale and unused.

Motley: But my tests have to run over a network to talk to a web service that has a computational intensive algorithm. It takes time. Nothing I can do.

Maven: You're testing your own code, right? Not the web service on the other end?

Motley: Yeah, so?

Maven: Replace the web service! You can create a stub or a mock object to take the place of the web service. The stub simply simulates the web service and returns a result for your test immediately. No network or long computation required.

Motley: That's cheating, dude! I'm not really testing the system then. It's fake!

Maven: Ahhhh, but we're unit testing here. The keyword is unit. You are testing your code that interacts with the web service, not doing a full integration test from end-to-end. Unit tests cover small, isolated chunks of code and simply validate the implementation of those small chunks.

Motley: But I still have to test the web service results!

Maven: Yes, but the web service will have its own set of unit tests. And just for the record, you also want your unit tests to:

○ Leave the system in the same state you found it (e.g. don't leave files sitting around that your test created)

○ Test very small chunks and not combine test cases (helps you quickly pinpoint the problem code)

○ Cover positive cases (the main logic) as well as negative logic (error cases)

○ Not be dependent on each other (don't expect unit tests to run in a particular order)

Motley: Okay, I'll try your suggestions. I guess if I want to replace components with stubs, I need to make sure they have well-defined interfaces so I can plug and play different implementations.

Maven: You are a smart man, Mot, a smart man.

______________________________

Maven's Pointer: Check out the infrastructure components that already exist to help with unit testing. Free tools for managed code include NUnit (http://www.nunit.org/) as a test framework and NMock (http://nmock.org/) for creating mock objects.

Maven's Resources: Pragmatic Unit Testing in C# with Nunit, by Andy Hunt and Dave Thomas, Pragmatic Bookshelf, ISBN: 0977616673, 2007.

Temporary Link: Technorati Profile