Introduction
As you may have noticed, I’ve kind of started to become a championship caliber pain in the butt about unit testing. I walk the halls of Gateway Ticketing saying “If your code isn’t easy to test, you are doing it wrong”. I keep giving my Unit Testing presentation to anyone that will listen. But I feel justified – unit testing is critical to writing clean, maintainable code.
One of the reasons people seem to frequently give for not doing unit testing is that “My code requires <some external dependency> and it’s too hard to configure for simple unit tests” or something like that. Okay, fair enough. I won’t point out how you should be using Dependency Injection to decouple that code and enable you to insert a mock or a stub or a different class for testing purposes. (Okay, I lied – technically I guess I did mention that. Sorry.) But I get that sometimes implementing a complete, formal TMockXXXX version of your interface (and you are coding against interfaces and not implementations, right?) is not something you want to do.
Mocks
In their simplest form, a mock object is simply an alternate implementation of a class that provides “fake” responses to method calls. For example, you have a class TCustomer that has a method GetCustomerName, and normally, that call goes to the production database and gets the name (a simple, unlikely example, I know, but you get the idea). So to avoid the call to the database, you just create TMockCustomer, and implement it’s call to GetCustomerName and have it return “George Jetson” every time. This enables you to test the class that is using TCustomer without having to hit the database at all.
But that can get a bit clumsy. What if you want to return different values based on different inputs? What if you find a bug based on specific input or output, and you want to create a unit test for that specific case? Then a mock class as described above gets harried, complicated, and hard to maintain.
Enter a Mocking Framework
What if we could have a framework that would allow us to implement any interface, and define easily and exactly what the inputs and outputs should be? That would be cool. This would enable you to easily create a mock object that can respond to method calls in defined ways in a flexible, easy to set up manner. This is what a mocking framework does.
Obviously something this flexible needs some powerful language features. Such a framework would have to be able to flex to dynamically implement an interface. It would have to be able to dynamically recognize method calls and respond accordingly. Fortunately, Delphi XE2 is up to the task. Delphi XE2 introduces the TVirtualInterface class that lets you dynamically implement any interface at runtime. Combine that with the new RTTI, and you have the ability to build a very powerful mocking framework.
And that is just what Vince Parrett of VSoft Technologies, author of the wonderful FinalBuilder, did. He has built a very cool and very powerful library called Delphi Mocks and released it as open source for all of us. Very cool – thanks, Vince. Delphi Mocks is available on GitHub under the very developer friendly Apache 2.0 License. Vince has written a nice “Getting Started” guide, but I wanted to write this article to build a very simple example of a pretty simple use case for mock objects. So let’s do that.
An Expensive Service
A typical use case for using a mock object is to replace a service that is “expensive”. Sometimes that means expensive as in “actually costs money”, but it will more likely mean expensive in CPU cycles, database connectivity, or anything else that requires an external dependency that causes your class under test to stop being tested in isolation and start being integrated with something else. Since a unit test should always test something atomically and leave nothing (database entries, files, charges on a credit card) lying around, any time that will happen when running a unit test, you probably should consider a stub or a mock object instead.
By “stub” I mean “a class that implements a particular interface but doesn’t really do anything”. It’s not exactly the same as a mock object in that the interface in question will normally not return anything but merely do things external to the class. A typical example is a logging class. If you are running unit tests, you don’t want your logging system writing logs all over the place every time you run your tests, so you create a Logger stub class that acts like your regular logger, but which actually doesn’t do anything. You can call it in your code, but you get nothing from it – which is what you want.
So let’s look at a simple, but “expensive” service. Consider the following code:
unit uCreditCardValidator;
interface
uses
SysUtils;
type
ICreditCardValidator = interface(IInvokable)
['{68553321-248C-4FD4-9881-C6B6B92B95AD}']
function IsCreditCardValid(aCreditCardNumber: string): Boolean;
procedure DoNotCallThisEver;
end;
TCreditCardValidator = class(TInterfacedObject, ICreditCardValidator)
function IsCreditCardValid(aCreditCardNumber: string): Boolean;
procedure DoNotCallThisEver;
end;
implementation
uses
Dialogs;
{ TAdder }
function TCreditCardValidator.IsCreditCardValid(aCreditCardNumber: string): Boolean;
begin
// Let's pretend this calls a SOAP server that charges $0.25 everytim
// you use it.
// For Demo purposes, we'll have the card be invalid if it the number 7 in it
Result := Pos('7', aCreditCardNumber) <= 0;
ShowMessage('You were just charged $0.25');
end;
procedure TCreditCardValidator.DoNotCallThisEver;
begin
// This one will charge the company $500! We should never
// call this!
end;
end.This unit declares two things, an ICreditCardValidator and a class that implements it, TCreditCardValidator. It simulates deciding a credit card is bad by saying any card number that has the number ‘7’ in it is bad. Otherwise, any string will be acceptable. It’s a demo class, obviously, but it illustrates a class that would be used only in production, as you get charged by a credit card validating service every time you call IsCreditCardValid. Clearly, you don’t want to be calling that whenever you run your tests. Thus, it seems likely that any collection of unit tests that wants to use this service would likely want to use a mock class.
A Class to Use the ICreditCardValidator
Mock classes really become useful when you are testing a class that consumes an expensive service. Thus, we’ll declare the following class, TCreditCardManager, which consumes ICreditCardValidator:
unit uCreditCardManager;
interface
uses
uCreditCardValidator
;
type
TCreditCardManager = class
private
FCCValidator: ICreditCardValidator;
public
constructor Create(aCCValidator: ICreditCardValidator);
function CreditCardIsValid(aCCString: string): Boolean;
end;
implementation
{ TAddingMachine }
function TCreditCardManager.CreditCardIsValid(aCCString: string): Boolean;
begin
Result := FCCValidator.IsCreditCardValid(aCCString);
end;
constructor TCreditCardManager.Create(aCCValidator: ICreditCardValidator);
begin
inherited Create;
FCCValidator := aCCValidator;
end;
end.This class is really simple – it just takes an ICreditCardValidator in it’s constructor and uses it to validate credit cards. As a demo class it is really simple, but a more complete class would have methods to make payments against the card, etc. But if, when testing this class, you pass it in an implementation of the ICreditCardValidator above, you’ll get charged $0.25 for every test you run. That’s not something you’d really want to do, so this class seems like a good candidate for using a mock object to replace the implementation of ICreditCardValidator.
Testing TCreditCardManager Can Be Expensive
So, the typical way to test TCreditCardManager might look like this:
procedure TestTCCValidator.TestValidateCreditCard;
var
ReturnValue: Boolean;
ExpensiveCCValidator: ICreditCardValidator;
ValidCard: string;
BadCard: string;
begin
ExpensiveCCValidator := TCreditCardValidator.Create;
FCCValidator := TCreditCardManager.Create(ExpensiveCCValidator);
ValidCard := '1112221'; // Rule is that a bad card has a '7' in it
BadCard := '6667666'; // ..so this one is bad
ReturnValue := FCCValidator.CreditCardIsValid(ValidCard);
CheckTrue(ReturnValue);
ReturnValue := FCCValidator.CreditCardIsValid(BadCard);
CheckFalse(ReturnValue);
end;
However, if you run this in the GUI test runner for DUnit, you’ll see this:
And of course, if you keep this up, the bill you get will not make your boss happy.
Testing with a Mock
So, to avoid the wrath of your boss, you should create a mock object that behaves like you want it to but that doesn’t end up costing anything. The first way you might do it is to create a new class that implements the ICreditCardValidator interface, but that does nothing or returns set values. But that is kind of clunky, and hard to customize. What you really want is what I mentioned earlier, an extensible mock that can be created an configured on the fly. That’s where Delphi Mocks comes in.
The Delphi.Mocks.pas unit declares a type TMock which takes a parameterized type, and which then can sort of morph itself into an implementation of that interface using the cool new-to-XE2 class called TVirtualInterface. TVirtualInterface basically allows you to implement an interface on the fly at runtime. Thus, you can create a generic class (or record, in the case of TMock) that can appear to be any interface you want it to be.
Thus, we can create a TMock that looks and acts like an ICreditCardValidator:
var
CCMock: TMock<ICreditCardValidator>;
begin
CCMock := TMock<ICreditCardValidator>.Create;
...
end;
Once we have that mock, we can tell it how to behave:
ValidCard := '1112221'; // Rule is that a bad card has a '7' in it
BadCard := '6667666'; // ..so this one is bad
CCMock.Setup.WillReturn(True).When.IsCreditCardValid(ValidCard);
CCMock.Setup.WillReturn(False).When.IsCreditCardValid(BadCard);
This code uses a nice fluent interface to be somewhat self-explanatory. It basically sets the mock up as follows: “When I pass in the valid string, return True. When I pass in the bad string, return False.” This is a basic definition that will allow your TCreditCardManager class to exercise itself with both good and bad input, allowing you to test your code with both kinds of responses. We can determine exactly what the inputs and outputs are and ensure that the mock displays the correct behavior and follows the business rules set out in the “real” implementation. Notice, too, that the When call, through the delightful magic of generics, is actually an implementation of the ICreditCardValidator interface, and thus is able to execute a real method call to the method from that interface. You even get support from Code Completion in the IDE.
Now, you can create the Credit Card Manager, pass it your mock object, and run tests with your mock input and output:
FCCValidator := TCreditCardManager.Create(CCMock);
ReturnValue := FCCValidator.CreditCardIsValid(ValidCard);
CheckTrue(ReturnValue);
ReturnValue := FCCValidator.CreditCardIsValid(BadCard);
CheckFalse(ReturnValue);
This way, you can exercise the instance and test it to your hearts content without incurring any of the expense associated with your “regular” implementation. If you need to add additional tests, you can simply tell the mock class what the new input and outputs are, and then run the appropriate tests.
Ensuring Code Is (or Is Not) Called
When writing tests, there may be times when you want to ensure that a given method is called with a frequency that you want to specify. Thus, you can write things like:
CCMock.Setup.Expect.AtLeastOnce.When.IsCreditCardValid(ValidCard);
// Ensure that the tests never call this. It costs $500!!
CCMock.Setup.Expect.Never.When.DoNotCallThisEver;
And then, when all the test are run, call:
on the mock object, and it will validate that the calls that you required were indeed called.
So, in the above example, if I were to call:
CCMock.Instance.DoNotCallThisEver;
I would get the following dialog:
…which of course tells me that I called a method in my tests that should not have ever been called.
There are also methods on the call to Expect interface that ensure that a certain call is made a minimum or maximum number of times, between a specified number of times, at least or at most a certain number of times, and as we saw, even never. Also, you can specify that one method be called before or after other methods. This enables you to dictate exactly how your object methods are called, and what should or should not happen when you run your tests.
Conclusion
So the Delphi Mock library is a very powerful tool for making it easy to write concise unit tests that don’t connect to “expensive” classes that could make testing difficult. The goal of writing testable code is a worthy one, and Delphi Mocks definitely can make it easier to reach that goal.