Have you ever though to verify the order of a method call in your Apex unit tests?
With Apex Mocks you can.
Sometimes ensure that a method is called after another one can add that plus strength to your unit tests.
Let’s have a look at an example: In our example, I’ll use a hypothetical API service that follows the Enterprise Pattern from the fflib-apex-common. This API performs few reads of data, it process that data and then consolidate it using the fflib_ISObjectUnitOfWork.
Does it sound complicated? Let’s have a look at the code
This it’s calling three selectors ( Opportunity, OpportunityLineItem and Contact) to read some data, then it calls the doStuff() method to perform some operation on these data, and then it registers some data in the UnitOfWork to be stored permanently.
Let’s say that the order on which the selectors are called matters for the correct reading of the data and we want to test it. (the MY_MOCKS variable is the Fflib_ApexMocks instance).
In the first part, we mock out the methods that interact with Our API. The magic is in the second part of the test method.
First of all, we create an instance of the fflib_inOrder to tell to Apex Mocks on which mock instance we want to verify in order. Those are passed as a list of objects together with the fflib_ApexMocks instance, however, the order they appear in that list is not relevant to the final verification.
Then is the time to call the method to test, followed by the three verify to assert the correct order of call.
There are three main differences with a classic Apex Mocks verification, firstly the verify method is called on the fflib_inOrder instance instead of the fflib_ApexMocks instance, then we have to specify explicitly the counter through the calls(Integer times). This is due to the fact that the counters ( times, atLeast, atMost ) are not currently fully implemented for the fflib_InOrder framework.
The last difference with a classic verify is that the order in which the verify are performed make the difference between a passing test and a one that fails. In our example, if we swap line 38 and 39 the test would fail.
Here is another example to show how the inOrder verify behaves;
this is going to test this part of our API method
In this test, we can observe that the inOrder with the calls(Integer times) performs a not greedy verification ( because it’s actually called three times ) and the fact that the inOrder is not strict ( in a strict verification the registerDirty is called once and then is called the registerNew ).
To perform a more strict verification we should verify every single call:
however, this test is not a fully strict verify, due to the not greedy nature of the verification. In fact, if in our example we call the registerNew at line 32 and 33 more times, this test still pass, but it won’t if we reduce them to only one.
With the fflib_InOrder you can finally check not only that your code is doing what you’d expect but that is done in the right order. This gives you the opportunity to write those tests that go forward the code coverage and makes your tests stronger and more descriptive. Happy unit testing.
The code of those examples can be downloaded from my GitHub repo.
- ApexMocks Framework Tutorial
- Simple Dependency Injection
- ApexMocks Generator
- Behaviour Verification
- Stubbing Dependencies
- Supported Features
- New Improved apex-mocks-generator
- ApexMocks Improvements – exception stubbing, base classes and more
- ApexMock blogs from Jesse Altman
- ApexMocks Capture Support
- Answering with Apex Mocks
- Counters in Apex Mocks verifications