Taking each question in turn:
Documentation
how I can understand what part of the online documentation is valid for my current release ? (2017a)
While you can use the online documentation for now, we only provide the documentation for a small number of previous releases online. Once the next release comes out I believe the documentation for R2017a will no longer be available on the website.
Because of this I would recommend using the documentation that should have been installed in your local installation. You can open your local documentation using the doc function.
Is there a filter that I did not see for that? i.e.: on bootstrap I can filter the documentation based on the version I am using (v4.0,v5.0)
On the Support site click on the Documentation button. On the page that brings up, click the "Other Releases" link immediately above the big blue box that says MATLAB (with Explore MATLAB in the lower part of the blue box.) From there you can access the documentation for the last ten releases.
Folder structure
When I set up the folder structure for my test, Does the test folder need to be outside of the current package?
-My_Package OR -My_Package -Tests
-->\+tests
You can organize your tests either way, though my personal preference would be for the tests to be in a separate directory.
If they're in a package you could use matlab.unittest.TestSuite.fromPackage to create a suite to run all of them. But in that case you'd have to use the package name in runtests calls if you wanted to use that to run individual tests.
Implementation questions
What is the point of having the Fixture adding the part to test to the path? (setupOnce or methods (TestClassSetup))
Which Fixture are you referring to, matlab.unittest.Fixtures.PathFixture?
If the software you're testing is not already on the MATLAB path for whatever reason, it will need to be made accessible to your test file. One way to do that is to add the directory containing it to the path temporarily which the PathFixture does. You could add it to the path manually in your setup using addpath, but then you'd have to remember to restore the path manually in the teardown for your test.
I used the term "restore the path" deliberately. Don't just rmpath it; using addpath to add a directory to the path that's already there is a no-op, so if later on that software moves to a directory that is on the path using an rmpath call would actually make the software no longer accessible after the test completes.
PathFixture will restore the path for you automatically when it is torn down, regardless of whether the test completes successfully or throws an error in the middle of execution.
All the Fixtures "clean up after themselves" automatically when they are torn down, which means you don't need to remember to go back and restore the previous state of MATLAB manually.
I want to check that my asserts that checks the input on my class are working correclty but I cannot specify the error id or the error message as most of them were set as multiple line messages so they are not recognised even if are the same. Is there a better way to check that an assert method fail as it supposed to do?
The verifyError function doesn't check for the text of messages, and that was a deliberate choice on our part. Changing the text of a message (to make it clearer or more informative) shouldn't cause a test to fail IMO. Neither should running a test on a machine that has error messages translated into Japanese, for example. The messages would be translated but the error identifiers would not be translated.
If your assert calls only include messages, not identifiers, there are two approaches I can think of off the top of my head. [Well, there is a third, to add the identifiers to the assert call as the second input using the syntax "assert(EXPRESSION, MSG_ID, ERRMSG, VALUE1, VALUE2, ...)" shown in the help text.]
The first is to just check that some error occurred using the metaclass object for the MException class. The error function throws an MException (that you could catch) that is displayed in red text in the Command Window.
testcase = matlab.unittest.TestCase.forInteractiveUse;
% Adding a 2-by-2 matrix and a 3-by-3 matrix will error
verifyError(testcase, @() [1 2; 3 4] + magic(3), ?MException)
% Or since I know the error identifier
verifyError(testcase, @() [1 2; 3 4] + magic(3), 'MATLAB:sizeDimensionsMustMatch')
Alternately you could catch the error, extract the message, and use verifyEqual to check that the message text matches. If you do this, though, you should also use verifyFail in the try portion of the try / catch block to handle the case where the function doesn't error.
% Buggy case; verifyEqual never gets reached
try
x = 1 + 1;
% Missing
% verifyFail(testcase, 'This operation should have thrown an error')
catch ME
verifyEqual(testcase, ME.message, 'Arrays have incompatible sizes for this operation.')
end
% Non-buggy case
try
x = [1 2; 3 4] + magic(3);
verifyFail(testcase, 'This operation should have thrown an error')
catch ME
verifyEqual(testcase, ME.message, 'Arrays have incompatible sizes for this operation.')
end
Note that this does not display "Verification passed." like the calls above did. Also note that if you run this in release R2017a both the examples above (with the message and with the identifier) will fail as we've changed the text of the error message from "Matrix dimension must agree." (in R2017a) to the above (in release R2022a) and we also changed error identifiers (which happens much more rarely, and usually when we split one very broad class of errors into two or more classes that are each more specific about the cause of the error.)
The case with the metaclass object will work in R2017a and R2022a.
Plugins
About the Code coverage report, I tested on 2017a but seem not implemented, on MatLab 2022a instead it does not recognise the test folder as countains any test. to let MatLab create a test suite I had to :
>> import matlab.unittest.TestSuite
>> suite =TestSuite.fromPackage('mypackage', 'IncludingSubpackages',true);
>> import matlab.unittest.plugins.CodeCoveragePlugin
>> runner = testrunner("textoutput");
>> results = runner.run(suite);
But that did not create any report, Did I miss something?
Nowhere did you actually create the plugin and add it to your test runner. Note the use of runner.addPlugin in the example on the matlab.unittest.plugins.CodeCoveragePlugin class (that documentation is for the most recent release, but the example on the corresponding page in release R2017a also uses addPlugin.
is the Mock framework avalable on 2017a?
