What are some ways to mock 'system' for unit testing?

I need to mock returns from calls to 'system' for the purpose of unit testing. I tried overloading the built-in by creating a 'system.m' function that lives in the same folder as my unit tests but the testing framework called foul on that approach and skips the tests that use it:

Warning: Function system has the same name as a MATLAB built-in. We suggest you rename the function to avoid a potential name conflict. 
> In matlab.unittest.TestSuite>temporarilyChangeFolderIfNeeded (line 881)
In matlab.unittest.TestSuite.fromFileCore_ (line 694)
In matlab.unittest.TestSuite.fromFile (line 178)
In matlab.unittest.internal.testbrowser/AlertHandler/callFunctionAndHandleAlerts
In matlab.unittest.internal.testbrowser/SuiteFromFileForTestImport/execute
In matlab.unittest.internal.testbrowser/TestModelService/loadTestFile
In matlab.unittest.internal.testbrowser/TestModelService/loadTestFiles
In matlab.unittest.internal.testbrowser/TestBrowserController/importTestFiles
In matlab.unittest.internal.testbrowser.TestBrowserActionsService.importFilesInJavaDesktop 

One approach is to create a wrapper method for 'system' in the class under test, then create a wrapper class that inherits 'myClass' that is used for testing:

class I want to test

classdef myClass
    methods 
        function [status,cmdout]=systemWrapper(varargin)            
            [status,cmdout]=system(varargin)
            % varargout parsing... blah blah
        end
    end
end

mock class called by tests to overload 'systemWrapper'

classdef myClassMocked < myClass
    methods
        function [status,cmdout]=systemWrapper(varargin)            
            [status,cmdout]=systemMock(varargin)
            % varargout parsing... blah blah
        end
    end
end

I think that should work, but it just smells a bit convoluted and seems like there should be a cleaner way to mock 'system' directly.

[dpb]

Never used the testing framework, but it's a warning, not an error, so I would think the first would still function as wanted.

Since in this case you delibertely alias system you could turn off the warning before by using with

[id,msg]=lastwarn;

at command line to get the precise warning id and then

warning('off',id)

before initiating the test. Reinstate the warning state afterwards, of course.

[Chris]

Thanks, @dpb, but the framework actually skips the test; it uses warnings rather than exceptions so the rest of the test suite can finish.

[dpb]

Well, that sucks, doesn't it? It was just a hypothesis, too bad it wasn't the right one.

If somebody doesn't come along with Framework experience and a better idea, I'd recomend to submit this to Mathworks as an official support request at <Product Support Page> for better approach and/or enhancement request to have a way to force the test despite the specific warning; it seems a reasonable use case for why one would really, indeed, want to alias the builtin.

Answer 1

[Nidhi]

Hi Chris,

I understand that you want to mock function files (not object methods) in MATLAB unit tests and are looking for a reliable approach.

MATLAB’s built-in mocking framework is designed for mocking object methods and properties, not standalone function files (https://www.mathworks.com/help/matlab/mock-dependencies-in-tests.html)[SS1] . For function files, the recommended approach is to use path manipulation so that your test calls a mock version of the function instead of the real one.

Here are two common methods:

1. Manual Path Manipulation: Place a mock version of the function (e.g., second.m) in a separate folder (e.g., mocks). Add this folder to the top of the MATLAB path before running your test. Here is a documentation which you can refer : https://www.mathworks.com/help/matlab/matlab_prog/function-precedence-order.html.
2. Using PathFixture in Unit Tests: The cleaner and more automated approach is to use matlab.unittest.fixtures.PathFixture in your test file. This temporarily adds the mocks folder to the path for the duration of the test. For example:

import matlab.unittest.fixtures.PathFixture;
testCase.applyFixture(PathFixture(fullfile(pwd,'mocks')));  

This ensures that when your function under test calls the target function, the mock is used instead of the original.

I hope this helps!

[Chris]

Thank you, Nidhi, I believe you are correct that the "intended" way to mock functions is to overload them using path management.