{"id":1011,"date":"2017-07-06T13:07:37","date_gmt":"2017-07-06T17:07:37","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=1011"},"modified":"2017-07-06T13:07:37","modified_gmt":"2017-07-06T17:07:37","slug":"dont-mock-me","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2017\/07\/06\/dont-mock-me\/","title":{"rendered":"Don’t Mock Me!"},"content":{"rendered":"\r\n

Hi folks, it's been a long time! Thanks for your patience as we have a lot of great incubating topics to discuss on the blog. Today I am excited to introduce David Hruska, who is the lead developer on an exciting new mocking framework that is part of MATLAB as of R2017b, and he is here to explore it a bit with you. Enjoy!<\/i><\/p>

\"\" <\/p>

Do you mock when writing code? No, I'm not talking about this<\/a> kind of mocking. I'm talking about replacing the dependencies of your system-under-test with mock objects to drive the system's behavior a particular way, or verify how it interacts with its collaborators. MATLAB release 2017a includes a mocking framework for just this purpose. Let's look at an example in action to see what this means in practice. Here's the interface for an Iterator<\/tt> class that we'll be using.<\/p>

classdef<\/span> Iterator < handle\r\n   properties<\/span> (Abstract, SetAccess=private)\r\n      Value;\r\n   end<\/span>\r\n   methods<\/span> (Abstract)\r\n      bool = hasNext(iter);\r\n      advance(iter);\r\n   end<\/span>\r\nend<\/span>\r\n<\/pre>
And here's an algorithm we want to test. It determines if a value is present in the iterator.<\/p>
function<\/span> bool = hasValue(iter, value)\r\nvalidateattributes(iter, {'Iterator'<\/span>}, {'scalar'<\/span>}, 'hasValue'<\/span>);\r\nvalidateattributes(value, {'numeric'<\/span>}, {'nonempty'<\/span>}, 'hasValue'<\/span>);\r\n\r\nbool = false;\r\nwhile<\/span> iter.hasNext\r\n   iter.advance;\r\n   if<\/span> iter.Value == value\r\n      bool = true;\r\n   end<\/span>\r\nend<\/span>\r\nend<\/span>\r\n<\/pre>
Constructing a mock<\/b><\/p>
To construct a mock, call the createMock<\/tt> method of the matlab.mock.TestCase<\/tt> class. Typically this would be used inside of a test method in a class which derives from matlab.mock.TestCase<\/tt>. However, for interactive experimentation at the command line, we'll first use the forInteractiveUse<\/tt> static method to obtain a TestCase<\/tt> instance. A call to the createMock<\/tt> method is all that's required to create a mock object. The framework creates a class that implements the necessary abstract properties and methods of the interface and constructs an instance. createMock<\/tt> also returns an associated behavior<\/tt> object for controlling the mock.<\/p>
testCase = matlab.mock.TestCase.forInteractiveUse;\r\n[mockIterator, behavior] = testCase.createMock(?Iterator);\r\n<\/pre>
To make the mock do something useful, we'll need to define its behavior. The behavior specification reads like a sentence:<\/p>
import matlab.mock.actions.AssignOutputs<\/span>;\r\nwhen(get(behavior.Value), then(AssignOutputs(1), then(AssignOutputs(2), then(AssignOutputs(3)))));\r\n<\/pre>
Here's what this code does: when the Value<\/tt> property is accessed, first return a value of 1<\/tt> . The next time the property is accessed, return a value of 2<\/tt> . Finally, return 3<\/tt> for any subsequent property accesses.<\/p>
Let's also set up the hasNext<\/tt> method to return true<\/tt> the first three times it's invoked and false<\/tt> thereafter. Use withAnyInputs<\/tt> to specify that this behavior should be performed regardless of any additional inputs passed to the method.<\/p>
when(withAnyInputs(behavior.hasNext), then(repeat(3, AssignOutputs(true)), then(AssignOutputs(false))));\r\n<\/pre>
With some basic behavior defined, we can now use the mock to test our algorithm.<\/p>
result = hasValue(mockIterator, 2);\r\ntestCase.verifyTrue(result, \"Expected hasValue to find 2.\"<\/span>);\r\n<\/pre>
Interactive verification passed.\r\n<\/pre>
The mock iterator was set up to return 1<\/tt> , then 2<\/tt> , then 3<\/tt> ; the hasValue<\/tt> function found the 2<\/tt> ; and the we've verified this outcome. Great!<\/p>
The example above uses a technique sometimes referred to as stubbing<\/i>: we have set up a mock to return pre-defined responses to drive the system in a particular way. We can also spy<\/i> on how the system interacts with its dependencies. Let's set up a new mock with slightly different behavior and pass it to hasValue<\/tt>.<\/p>
[mockIterator, behavior] = testCase.createMock(?Iterator);\r\nwhen(get(behavior.Value), then(AssignOutputs(1)));\r\nwhen(withAnyInputs(behavior.hasNext), then(repeat(10, AssignOutputs(true)), then(AssignOutputs(false))));\r\n\r\nresult = hasValue(mockIterator, 1);\r\ntestCase.assertTrue(result, \"Expected hasValue to find 1.\"<\/span>);\r\n<\/pre>
Interactive assertion passed.\r\n<\/pre>
Here we've defined the mock to always return value 1<\/tt> when its Value<\/tt> property is accessed. The hasNext<\/tt> method returns true<\/tt> the first 10<\/tt> times it is called, indicating that there are 10<\/tt> values in the iterator. It would be reasonable to expect an efficient implementation of hasValue<\/tt> to \"short-circuit\" once it has found the first value and stop checking the remaining elements in the iterator. Let's see if this is what happened, though. When the mock is constructed, it automatically begins recording information about its interactions. In addition to defining how the mock should act, the behavior<\/tt> also provides access to this spy information. Let's use this information to verify that Value<\/tt> was accessed exactly once, as an efficient implementation would do.<\/p>
import matlab.mock.constraints.WasAccessed<\/span>;\r\ntestCase.verifyThat(behavior.Value, WasAccessed('WithCount'<\/span>,1), ...<\/span>\r\n    \"Expected Value to be accessed only once.\"<\/span>);\r\n<\/pre>
Interactive verification failed.\r\n\r\n----------------\r\nTest Diagnostic:\r\n----------------\r\nExpected Value to be accessed only once.\r\n\r\n---------------------\r\nFramework Diagnostic:\r\n---------------------\r\nWasAccessed failed.\r\n--> Property 'Value' was not accessed the expected number of times.\r\n    \r\n    Actual property access count:\r\n            10\r\n    Expected property access count:\r\n             1\r\n\r\nSpecified property access:\r\n    PropertyGetBehavior\r\n        <IteratorMock_1>.Value\r\n<\/pre>
The qualification failed because the algorithm accessed the property 10<\/tt> times. This could be addressed by returning immediately from the function after it finds the first instance of the desired value.<\/p>
function<\/span> bool = efficientHasValue(iter, value)\r\nvalidateattributes(iter, {'Iterator'<\/span>}, {'scalar'<\/span>}, 'efficientHasValue'<\/span>);\r\nvalidateattributes(value, {'numeric'<\/span>}, {'nonempty'<\/span>}, 'efficientHasValue'<\/span>);\r\n\r\nbool = false;\r\nwhile<\/span> iter.hasNext\r\n   iter.advance;\r\n   if<\/span> iter.Value == value\r\n      bool = true;\r\n      % Done! We've found the value.<\/span>\r\n      return<\/span>;\r\n   end<\/span>\r\nend<\/span>\r\nend<\/span>\r\n<\/pre>
Returning to the original algorithm, let's write one more test. This time let's write a negative test to ensure the proper error checking is performed on the value<\/tt> input to hasValue<\/tt>, rejecting empty values. For this test, we don't plan to even use an Iterator, but we do need to provide a valid instance because the function also validates the iterator input. Therefore, we can simply construct a mock but define no behavior. The mock is then passed to the function being tested.<\/p>
dummyIterator = testCase.createMock(?Iterator);\r\ntestCase.verifyError(@()hasValue(dummyIterator, []), 'MATLAB:hasValue:expectedNonempty'<\/span>);\r\n<\/pre>
Interactive verification passed.\r\n<\/pre>
Comparison with Hand-Coded Mocks<\/b><\/p>
The tests above could have been performed using hand-written mock subclasses of the Iterator<\/tt> interface. However, this can lead to one of two things: an inventory of many different mocks (stubs, spies, fakes, etc.) or one very complicated mock class that might even be more complicated that the code you're trying to test! For example, we might have been tempted to reuse the hand-written stub or spy for the negative test above which could result in undesirable coupling. By using the mocking framework, we achieve independence of each test.<\/p>
Also, as your design evolves, your interfaces might change: new abstract properties or methods could be added. Or maybe the access permissions might change. This is particularly likely early in the development process. Hand-written mocks would need to be updated individually to relect the changes to the interface. The mocking framework, on the other hand, automatically implements all abstract members required by the interface with the correct access permissions each time createMock<\/tt> is called.<\/p>
In summary, compared to hand-coded mocks, the mocking framework provides<\/p>