Merge pull request #20 from bauglir/matlab-r2016b-compatibility

MATLAB R2016b compatibility

architecture/html/matlab_xunit_architecture.html

@@ -98,9 +98,10 @@
      ...</pre><pre>  function C
      ...</pre><pre>  function D
      ...</pre><p>The first function in the file, <tt>A</tt>, has the same name as the file.  When other code outside this function calls <tt>A</tt>, it is this first function that gets called.  Functions <tt>B</tt>, <tt>C</tt>, and <tt>D</tt> are called <i>subfunctions</i>. Normally, these subfunctions are only visible to and can only be called by <tt>A</tt>.  The only way that code elsewhere might be able to call <tt>B</tt>, <tt>C</tt>, or <tt>D</tt> is if function <tt>A</tt> forms handles to them and passes those handles out of its scope.  Normally this would be done by returning the function handles as output arguments.</p><p>Note that no code executing outside the scope of a function in A.m can form function handles to <tt>B</tt>, <tt>C</tt>, or <tt>D</tt>, or can even determine that these functions exist.</p><p>This obviously poses a problem for test discovery!</p><p>The MATLAB xUnit solution is to establish the following convention for subfunction-based tests.  The first function in a test M-file containing subfunction tests has to begin with these lines:</p><pre>  === File A.m ===
-  function test_suite = A
-  initTestSuite;
-  ...</pre><p><tt>initTestSuite</tt> is a <i>script</i> that runs in the scope of the function <tt>A</tt>. <tt>initTestSuite</tt> determines which subfunctions are test functions, as well as setup or teardown functions.  It forms handles to these functions and constructs a set of FunctionHandleTestCase objects, which function <tt>A</tt> returns as the output argument <tt>test_suite</tt>.</p><h2>TestRunMonitor<a name="6"></a></h2><p>The abstract <tt>TestRunMonitor</tt> class defines the interface for an object that "observe" the in-progress execution of a test suite.  MATLAB xUnit provides two subclasses of <tt>TestRunMonitor</tt>:</p><div><ul><li><tt>TestRunLogger</tt> silently logs test suite events and captures the details of any test failures or test errors.</li><li><tt>CommandWindowTestRunDisplay</tt> prints the progress of an executing test suite to the Command Window.</li></ul></div><p><img vspace="5" hspace="5" src="class_diagram_c.gif" alt=""> </p><p>A TestRunMonitor is passed to the <tt>run()</tt> method of a TestComponent object. The <tt>run()</tt> method calls the appropriate notification methods of the monitor.</p><p>Here is the output when using the CommandWindowTestRunDisplay object on the MATLAB xUnit's own test suite:</p><pre>  runxunit
+  function testSuite = A
+  testSuite = buildFunctionHandleTestSuite(localfunctions);
+  ...</pre>
+  <p><tt>buildFunctionHandleTestSuite(localfunctions)</tt> determines which subfunctions are test functions, as well as setup or teardown functions.  It forms handles to these functions and constructs a set of FunctionHandleTestCase objects, which function <tt>A</tt> returns as the output argument <tt>testSuite</tt>.</p><h2>TestRunMonitor<a name="6"></a></h2><p>The abstract <tt>TestRunMonitor</tt> class defines the interface for an object that "observe" the in-progress execution of a test suite.  MATLAB xUnit provides two subclasses of <tt>TestRunMonitor</tt>:</p><div><ul><li><tt>TestRunLogger</tt> silently logs test suite events and captures the details of any test failures or test errors.</li><li><tt>CommandWindowTestRunDisplay</tt> prints the progress of an executing test suite to the Command Window.</li></ul></div><p><img vspace="5" hspace="5" src="class_diagram_c.gif" alt=""> </p><p>A TestRunMonitor is passed to the <tt>run()</tt> method of a TestComponent object. The <tt>run()</tt> method calls the appropriate notification methods of the monitor.</p><p>Here is the output when using the CommandWindowTestRunDisplay object on the MATLAB xUnit's own test suite:</p><pre>  runxunit
   Starting test run with 92 test cases.
   ....................
   ....................
@@ -313,15 +314,14 @@
 % subfunction tests has to begin with these lines:
 %
 %    === File A.m ===
-%    function test_suite = A
-%    initTestSuite;
+%    function testSuite = A
+%    testSuite = buildFunctionHandleTestSuite(localfunctions);
 %    ...
 %
-% |initTestSuite| is a _script_ that runs in the scope of the function |A|.
-% |initTestSuite| determines which subfunctions are test functions, as well as setup
-% or teardown functions.  It forms handles to these functions and constructs a
-% set of FunctionHandleTestCase objects, which function |A| returns as the
-% output argument |test_suite|.
+% |buildFunctionHandleTestSuite(localfunctions)| determines which subfunctions
+% are test functions, as well as setup or teardown functions.  It forms
+% handles to these functions and constructs a set of FunctionHandleTestCase
+% objects, which function |A| returns as the output argument |testSuite|.
 
 %% TestRunMonitor
 % The abstract |TestRunMonitor| class defines the interface for an object that

architecture/matlab_xunit_architecture.m

@@ -179,15 +179,14 @@
 % subfunction tests has to begin with these lines:
 %
 %    === File A.m ===
-%    function test_suite = A
-%    initTestSuite;
+%    function testSuite = A
+%    testSuite = buildFunctionHandleTestSuite(localfunctions);
 %    ...
 %
-% |initTestSuite| is a _script_ that runs in the scope of the function |A|.
-% |initTestSuite| determines which subfunctions are test functions, as well as setup
-% or teardown functions.  It forms handles to these functions and constructs a
-% set of FunctionHandleTestCase objects, which function |A| returns as the
-% output argument |test_suite|.
+% |buildFunctionHandleTestSuite(localfunctions)| determines which subfunctions
+% are test functions, as well as setup or teardown functions.  It forms handles
+% to these functions and constructs a set of FunctionHandleTestCase objects,
+% which function |A| returns as the output argument |testSuite|.
 
 %% TestRunMonitor
 % The abstract |TestRunMonitor| class defines the interface for an object that

architecture/testSample.m

@@ -1,5 +1,5 @@
-function test_suite = testSample
-initTestSuite;
+function testSuite = testSample
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testMyCode
 assertEqual(1, 1);

doc/exSubfunctionTests.m

@@ -6,10 +6,10 @@
 % Name your M-file beginning or ending with "test", like
 % "testMyFunc".  Start by putting the following two lines at the
 % beginning of the file.  It's important that the output variable
-% name on line 1 be |test_suite|.
+% name on line 1 be |testSuite|.
 %
-%    function test_suite = testMyFunc
-%    initTestSuite;
+%    function testSuite = testMyFunc
+%    testSuite = buildFunctionHandleTestSuite(localfunctions);
 %
 % Next, add subfunctions to the file.  Each subfunction beginning
 % or ending with "test" becomes an individual test case.

doc/example_subfunction_tests/testFliplr.m

@@ -1,5 +1,5 @@
-function test_suite = testFliplr
-initTestSuite;
+function testSuite = testFliplr
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testFliplrMatrix
 in = magic(3);

doc/examples_general/testBadSinTest.m

@@ -1,5 +1,5 @@
-function test_suite = testBadSinTest
-initTestSuite;
+function testSuite = testBadSinTest
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testSinPi
 % Example of a failing test case.  The test writer should have used

doc/examples_general/testCos.m

@@ -1,5 +1,5 @@
-function test_suite = testCos
-initTestSuite;
+function testSuite = testCos
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testTooManyInputs
 assertExceptionThrown(@() cos(1, 2), 'MATLAB:maxrhs');

doc/examples_general/testSetupExample.m

@@ -1,5 +1,5 @@
-function test_suite = testSetupExample
-initTestSuite;
+function testSuite = testSetupExample
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function fh = setup
 fh = figure;

doc/examples_general/testWithSetupError.m

@@ -1,8 +1,8 @@
-function test_suite = testWithSetupError
+function testSuite = testWithSetupError
 %Example of a test with an error.  The setup function calls cos with
 %too many input arguments.
 
-initTestSuite;
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testData = setup
 testData = cos(1, 2);

doc/html/exException.html

@@ -81,8 +81,8 @@
 </pre><p><tt>assertExceptionThrown</tt> verifies that when <tt>f()</tt> is called, an error results with the specified error identifier.</p><p>Here's our error condition test for the <tt>cos</tt> function.</p><pre class="codeinput">cd <span class="string">examples_general</span>
 type <span class="string">testCos</span>
 </pre><pre class="codeoutput">
-function test_suite = testCos
-initTestSuite;
+function testSuite = testCos
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testTooManyInputs
 assertExceptionThrown(@() cos(1, 2), 'MATLAB:maxrhs');

doc/html/exSubfunctionTests.html

@@ -65,13 +65,13 @@
 
 
 
-  </style></head><body><div class="content"><h1><a href="../index.html">MATLAB xUnit Test Framework</a>: How to Put Multiple Test Cases in One M-file</h1><p>The Quick Start example showed how you can write a simple M-file to be a single test case.  This example shows you how to put multiple test cases in one M-file.</p><p>Name your M-file beginning or ending with "test", like "testMyFunc".  Start by putting the following two lines at the beginning of the file.  It's important that the output variable name on line 1 be <tt>test_suite</tt>.</p><pre>  function test_suite = testMyFunc
-  initTestSuite;</pre><p>Next, add subfunctions to the file.  Each subfunction beginning or ending with "test" becomes an individual test case.</p><p>The directory example_subfunction_tests contains a test M-file containing subfunction test cases for the <tt>fliplr</tt> function.</p><pre class="codeinput">cd <span class="string">example_subfunction_tests</span>
+  </style></head><body><div class="content"><h1><a href="../index.html">MATLAB xUnit Test Framework</a>: How to Put Multiple Test Cases in One M-file</h1><p>The Quick Start example showed how you can write a simple M-file to be a single test case.  This example shows you how to put multiple test cases in one M-file.</p><p>Name your M-file beginning or ending with "test", like "testMyFunc".  Start by putting the following two lines at the beginning of the file.  It's important that the output variable name on line 1 be <tt>testSuite</tt>.</p><pre>  function testSuite = testMyFunc
+  testSuite = buildFunctionHandleTestSuite(localfunctions);</pre><p>Next, add subfunctions to the file.  Each subfunction beginning or ending with "test" becomes an individual test case.</p><p>The directory example_subfunction_tests contains a test M-file containing subfunction test cases for the <tt>fliplr</tt> function.</p><pre class="codeinput">cd <span class="string">example_subfunction_tests</span>
 
 type <span class="string">testFliplr</span>
 </pre><pre class="codeoutput">
-function test_suite = testFliplr
-initTestSuite;
+function testSuite = testFliplr
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function testFliplrMatrix
 in = magic(3);
@@ -97,11 +97,10 @@
 %
 % Name your M-file beginning or ending with "test", like
 % "testMyFunc".  Start by putting the following two lines at the
-% beginning of the file.  It's important that the output variable
-% name on line 1 be |test_suite|.
+% beginning of the file.
 %
-%    function test_suite = testMyFunc
-%    initTestSuite;
+%    function testSuite = testMyFunc
+%    testSuite = buildFunctionHandleTestSuite(localfunctions);
 %
 % Next, add subfunctions to the file.  Each subfunction beginning
 % or ending with "test" becomes an individual test case.

doc/html/exTestFixtures.html

@@ -68,8 +68,8 @@
   </style></head><body><div class="content"><h1><a href="../index.html">MATLAB xUnit Test Framework</a>: How to Write Tests That Share Common Set-Up Code</h1><p>Sometimes you want to write a set of test cases in which the same set of initialization steps is performed before each test case, or in which the same set of cleanup steps is performed after each test case.  This set of common <i>setup</i> and <i>teardown</i> code is called a <i>test fixture</i>.</p><p>In subfunction-based test files, you can add subfunctions whose names begin with "setup" and "teardown".  These functions will be called before and after every test-case subfunction is called.  If the setup function returns an output argument, that value is saved and passed to every test-case subfunction and also to the teardown function.</p><p>This example shows a setup function that creates a figure and returns its handle.  The figure handle is passed to each test-case subfunction.  The figure handle is also passed to the teardown function, which cleans up after each test case by deleting the figure.</p><pre class="codeinput">cd <span class="string">examples_general</span>
 type <span class="string">testSetupExample</span>
 </pre><pre class="codeoutput">
-function test_suite = testSetupExample
-initTestSuite;
+function testSuite = testSetupExample
+testSuite = buildFunctionHandleTestSuite(localfunctions);
 
 function fh = setup
 fh = figure;