Month: April 2014

Enhanced Mock Mocks

Well color me surprised, my last article on mocking in apex was, well, a little more popular than I thought it would be. I was happy that so may people enjoyed it, but it got me thinking, “Bob, you handsome and brilliant, yet refreshingly humble man, you can do more for your fans!” After an obligatory back patting, I set off to add more features. This will build entirely off of the last article. In fact, you are doing yourself a disservice if you don’t read it post haste.

We start with a change to add parameter matcher, a handy feature for times when you are not 100% sure the value that is going into you method. All we need is an enum.

This is the bare minimum to work while still providing room for enhancement. The only thing in this enum is the value anyVal. What we are saying is when this is used, accept any value. Next I modified my interface, services and test to give the method getAuthCode a Datetime parameter. The OrderService will pass in, making this almost impossible to mock without matchers. There also needs to be a change in Mock maker to handle this new condition.

It isn’t much different than it was two weeks ago, except now it checks if the parameter is a matcher. If it is, and since there is only one possible value it could be, we just skip any check on the parameter and continue to the next. Now we can change our test to work with this new code.

Now our call to getAuthCode will work no matter what we pass in. A quick test run shows both tests passing… but that isn’t right, now is it? We only changed one test yet both still pass. It isn’t enough to simply check the parameters, we need to check the number of them as well. Otherwise our loop could give false positives like in this case, or throw exceptions. Let’s put a halt to that right now.

One extra line asserts that the number of parameters passed in is the same as those expected.

There is another case we are still not testing for. If you remember last time, I used mocks to return a purposeful bad value to test out some error handling. What if we wanted to test what happens when the service we are mocking throws an exception itself? We need some more code for this one but before that, we need an exception to throw.

Phew, that was a lot of work, but I soldier on. Next is some code in our service to expect such an exception.


Now we need to get MockMaker to throw the exception at the right time.

This getCall method keeps getting all of the attention. Another conditional now checks if the return value is actually an exception and if so, it throws it. The only thing left is the test.

The only real difference here is that the addCall for processPayment has an exception passed into it and the end assert reflects the caught exception.

With just a bit of work, MockMaker now checks the quantity of parameters, uses matchers to check for values that might not be known when the test is started, and throws exceptions on command. While not on par with some other language’s mock suits, it can go a long way to making life easier for a developer.

Mock Mocks in Apex

I love mocking frameworks. I love the ability to isolate a unit of code so I can make smaller, more coherent tests. I have grown accustom to them during my time with java and I would love to use them with apex. The problem is that mocking frameworks rely heavily on robust reflection, a feature apex sorrily lacks.

Sorry. Lost the happy, but the happy's back!
Sorry. Lost the happy, but the happy’s back!

While we cannot yet simply tell a method to generate a mock class, maybe we can make an approximation. A lightweight class that can be substituted for the real thing when testing a class that relies on it could work in many cases. How to get the mock class in there though, that is the question. While Apex is missing most of the necessary reflection, it is not missing all of it. Enter a little known blog, by a man called Jesse Altman, that goes into dependency injection with Apex. That, my friends, is the foundation of what I will go into here. If you didn’t click the link above, and I don’t know why you wouldn’t have, read the article on dependency injection right now. Seriously, if you go on without reading it I will be disappointed in you.

Are you done? And no lying, I will know. So, I have my classes and custom settings pretty much the same as the one from Jesse’s blog post and will be building from there. The best place to start with a blog post on mocks and unit tests is probably a unit test. The unit test will initially test the the classes as they are.

My service just just calls processPayment on a PaymentInterface, nothing special there. The test inserts a custom setting first, grabs the return value from processOrderPayment and verifies the result. Not too much going on here, certainly not deserving a post. Yet. Lets spice this test up.

Look at that, injecting an inner class from within the test worked just fine too. The problem is that this is a trivial example. Why bother mocking? Let’s make this a bit more complex.

I have changed the interface to have the method getAuthCode and added a string parameter to processPayment. The service now checks for a non null authCode and throws an exception if it is. Our mock has had its methods changed accordingly and now, process payment verifies the parameter passed to it. This is closer to our mocks, but now we have a branch we can only test by adding another mock. Inconvenient indeed. One last change, one last push over the finish line. A new class will get us where we need to go.

This hefty class will let us reuse the same mocks multiple times. I wont break this down line for line but I will summarize it. The command object holds parameters to verify against and return values to… return. The method add call adds the call to a map containing a list of command objects, keyed to the method name being mocked. The calls to a particular method must be mocked in the order they will be run. The method getCall gets the command for a method, verifies the parameters are the same and returns the stored return value. What does this look like in practice? Ask, and ye shall receive.

The mock now extends MockMaker and does nothing more than wrap different calls to getCall. The test methods (yes, now there are two) mock out the calls to the payment service with MockMaker.addCall. We can now use the single mock, injected into the OrderService via the factory, to run multiple tests. This isn’t perfect but for services with call-outs or just very heavy methods, this can be a real help.