Should I rather write scripts for tests and use the runtests function or define test classes which inherit from the matlab.unittest.TestCase class?
5 views (last 30 days)
Andy Campbell on 26 Nov 2018
Edited: Andy Campbell on 26 Nov 2018
Tests can be written as scripts, functions or classes, and which interface you use depends on your preference and comfort level with different MATLAB constructs. Scripts are intended to allow you to quickly get started writing test scripts, and also can be written in a way to facilitate being able to run them even when you are working in a MATLAB version without the test framework (introduced in 13a) or the runtests function (introduced in 13b). However, they are quite limited in their set of features. For example, there are no interfaces to help setting up and tearing down your test fixtures. Also, you don't get a testCase instance in your test when you write with scripts and so you don't have access to helpful functions such as verifyEqual. This means that you need to produce your failures all on your own using the assert function. So the following are examples of roughly equivalent qualifications:
assert(actual == expected)
assert(abs(expected-actual)/expected < reltol)
testCase.verifyEqual(actual,expected, 'RelTol', reltol)
However, verifyEqual also handles many edge cases for you such as explicitly checking the class of the values, handling non-scalar values well, and providing more diagnostics. For the example above using relative tolerance above here is the message you see when the assert call fails:
>> assert(abs(expected-actual)/expected < reltol)
...and here is the message when verifyEqual fails:
>> testCase.verifyEqual(actual, expected, 'RelTol',reltol)
--> The numeric values are not equal using "isequaln".
--> The error was not within relative tolerance.
--> Failure table:
Actual Expected Error RelativeError RelativeTolerance
______ ________ _____ _____________ _________________
4 5 -1 -0.2 0.15
In addition to these benefits you also get access to many other features such as parameterized tests, test tags, and shared test fixtures.
However, you may not need these other features. You don't have to use them when you use classes and using classes is generally pretty stratightforward to get started, but if you or your colleagues are not comfortable using classes, scripts are a perfectly fine way to get started. Then if you find you would be interested in some other features that functions or classes enable you can start using them whenever you need.
Generally speaking there is nothing you can do with script based tests that you can't do with function based tests. Also there is generally nothing you can do with function based tests that you can't do with classes. The converse is not true. There is more you can do with classes than functions and more with functions than scripts.
However, sometimes you just want to write a simple test script (or perhaps function), and its entirely that easy barrier to entry that scripts enable and were designed for.
Hope that helps!