Main Content

runtests

Run set of tests

Description

example

testResults = runtests runs all the tests in your current folder and returns the test results.

example

testResults = runtests(tests) runs the specified tests.

example

testResults = runtests(___,Name,Value) specifies options using one or more name-value arguments in addition to any of the input argument combinations in previous syntaxes. For example, testResults = runtests("IncludeSubfolders",true) runs all the tests in the current folder and any of its subfolders.

example

[testResults,coverageResults] = runtests(___) also returns the results of the code coverage analysis when you specify the ReportCoverageFor name-value argument. (since R2023b)

Examples

collapse all

Create a folder myExample in your current working folder, and change into that folder.

In the myExample folder, create a test script, typeTest.m.

%% Test double class
exp = 'double';
act = ones;
assert(isa(act,exp))

%% Test single class
exp = 'single';
act = ones('single');
assert(isa(act,exp))

%% Test uint16 class
exp = 'uint16';
act = ones('uint16');
assert(isa(act,exp))

In the myExample folder, create a test script, sizeValueTest.m.

%% Test size
exp = [7 13];
act = ones([7 13]);
assert(isequal(size(act),exp))

%% Test values
act = ones(42);
assert(unique(act) == 1)

Run all tests in the current folder.

runtests
Running sizeValueTest
..
Done sizeValueTest
__________

Running typeTest
...
Done typeTest
__________


ans = 

  1x5 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   5 Passed, 0 Failed, 0 Incomplete.
   0.038077 seconds testing time.

MATLAB® ran 5 tests. There are 2 passing tests from sizeValueTest and 3 passing tests from typeTest.

Create the test file shown below, and save it as runtestsExampleTest.m on your MATLAB path.

function tests = runtestsExampleTest
tests = functiontests(localfunctions);

function testFunctionOne(testCase)

Run the tests.

results = runtests('runtestsExampleTest.m');
Running runtestsExampleTest
.
Done runtestsExampleTest
__________

If it does not exist, create the runtestsExampleTest.m test file from the previous example.

Create a subfolder, tmpTest, and, in that folder, create this runtestsExampleSubfolderTest.m test file.

function tests = runtestsExampleSubfolderTest
tests = functiontests(localfunctions);

function testFunctionTwo(testCase)

Run the tests from the folder above tmpTest by specifying IncludeSubfolders as true. The runtests function runs the tests in both the current folder and the subfolder.

results = runtests(pwd,"IncludeSubfolders",true);
Running runtestsExampleTest
.
Done runtestsExampleTest
__________

Running runtestsExampleSubFolderTest
.
Done runtestsExampleSubFolderTest
__________

If you do not specify the IncludeSubfolders name-value argument, runtests does not run the test in the subfolder.

results = runtests(pwd);
Running runtestsExampleTest
.
Done runtestsExampleTest
__________

When your current folder is a project root folder or when you pass the path to a project root folder to the runtests function, runtests runs all test files contained in the specified project that are labeled with the Test classification.

This example assumes that a project folder at C:\projects\project1 contains test files that are labeled with the Test classification. Change your current folder to the project root folder and run the tests in the project.

cd 'C:\projects\project1'
runtests

Alternatively, you can run the tests by opening project1. Close the project when you are finished.

proj = openProject('C:\projects\project1');
runtests
close(proj)

As another alternative, run the tests in the project by passing the full path to the project root folder to runtests.

runtests('C:\projects\project1')

Create this function-based test in a file named runInParallelTest.m in your current folder.

function tests = runInParallelTest
tests = functiontests(localfunctions);

function testA(testCase)
verifyEqual(testCase,5,5);

function testB(testCase)
verifyTrue(testCase,logical(1));

function testC(testCase)
verifySubstring(testCase,'SomeLongText','Long');

function testD(testCase)
verifySize(testCase,ones(2,5,3),[2 5 3]);

function testE(testCase)
verifyGreaterThan(testCase,3,2);

function testF(testCase)
verifyEmpty(testCase,{},'Cell array is not empty.');

function testG(testCase)
verifyMatches(testCase,'Some Text','Some [Tt]ext');

Run the tests in parallel. Running tests in parallel requires Parallel Computing Toolbox™. The testing framework might vary the order and number of groups or which tests it includes in each group.

results = runtests("runInParallelTest.m","UseParallel",true);
Split tests into 7 groups and running them on 4 workers.
----------------
Finished Group 2
----------------
Running runInParallelTest
.
Done runInParallelTest
__________


----------------
Finished Group 3
----------------
Running runInParallelTest
.
Done runInParallelTest
__________


----------------
Finished Group 1
----------------
Running runInParallelTest
.
Done runInParallelTest
__________


----------------
Finished Group 4
----------------
Running runInParallelTest
.
Done runInParallelTest
__________


----------------
Finished Group 6
----------------
Running runInParallelTest
.
Done runInParallelTest
__________


----------------
Finished Group 5
----------------
Running runInParallelTest
.
Done runInParallelTest
__________


----------------
Finished Group 7
----------------
Running runInParallelTest
.
Done runInParallelTest
__________

In your working folder, create testZeros.m. This class contains four test methods.

classdef testZeros < matlab.unittest.TestCase
    properties (TestParameter)
        type = {'single','double','uint16'};
        outSize = struct('s2d',[3 3], 's3d',[2 5 4]);
    end
    
    methods (Test)
        function testClass(testCase, type, outSize)
            testCase.verifyClass(zeros(outSize,type), type);
        end
        
        function testSize(testCase, outSize)
            testCase.verifySize(zeros(outSize), outSize);
        end
        
        function testDefaultClass(testCase)
            testCase.verifyClass(zeros, 'double');
        end
        function testDefaultSize(testCase)
            testCase.verifySize(zeros, [1 1]);
        end
        
        function testDefaultValue(testCase)
            testCase.verifyEqual(zeros,0);
        end
    end
end

The full test suite has 11 test elements: 6 from the testClass method, 2 from the testSize method, and 1 each from the testDefaultClass, testDefaultSize, and testDefaultValue methods.

At the command prompt, run all the parameterizations for the testSize method.

runtests('testZeros/testSize')
Running testZeros
..
Done testZeros
__________


ans = 

  1x2 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   2 Passed, 0 Failed, 0 Incomplete.
   0.05128 seconds testing time.

The runtests function executed the two parameterized tests from the testSize method. Alternatively, you can specify the test procedure name with runtests('testZeros','ProcedureName','testSize').

Run the test elements that use the outSize parameter property.

runtests('testZeros','ParameterProperty','outSize')
Running testZeros
........
Done testZeros
__________


ans = 

  1x8 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   8 Passed, 0 Failed, 0 Incomplete.
   0.070188 seconds testing time.

The runtests function executed eight tests that use the outSize parameter property: six from the testClass method and two from the testSize method.

Run the test elements that use the single parameter name.

runtests('testZeros','ParameterName','single')
Running testZeros
..
Done testZeros
__________


ans = 

  1x2 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   2 Passed, 0 Failed, 0 Incomplete.
   0.012925 seconds testing time.

The runtests function executed the two tests from the testClass method that use the outSize parameter name.

Since R2023b

Run your tests and collect code coverage results by using the runtests function.

In a file named quadraticSolver.m in your current folder, create the quadraticSolver function. The function takes as inputs the coefficients of a quadratic polynomial and returns the roots of that polynomial. If the coefficients are specified as nonnumeric values, the function throws an error.

function roots = quadraticSolver(a,b,c)
% quadraticSolver returns solutions to the
% quadratic equation a*x^2 + b*x + c = 0.

if ~isa(a,"numeric") || ~isa(b,"numeric") || ~isa(c,"numeric")
    error("quadraticSolver:InputMustBeNumeric", ...
        "Coefficients must be numeric.")
end

roots(1) = (-b + sqrt(b^2 - 4*a*c)) / (2*a);
roots(2) = (-b - sqrt(b^2 - 4*a*c)) / (2*a);

end

To test the quadraticSolver function, create the SolverTest class in a file named SolverTest.m in your current folder. Define three Test methods that test the function against real solutions, imaginary solutions, and nonnumeric inputs.

classdef SolverTest < matlab.unittest.TestCase
    methods (Test)
        function realSolution(testCase)
            actSolution = quadraticSolver(1,-3,2);
            expSolution = [2 1];
            testCase.verifyEqual(actSolution,expSolution)
        end
        function imaginarySolution(testCase)
            actSolution = quadraticSolver(1,2,10);
            expSolution = [-1+3i -1-3i];
            testCase.verifyEqual(actSolution,expSolution)
        end
        function nonnumericInput(testCase)
            testCase.verifyError(@()quadraticSolver(1,"-3",2), ...
                "quadraticSolver:InputMustBeNumeric")
        end
    end
end

Run the tests in the SolverTest class and also perform a code coverage analysis by specifying the ReportCoverageFor name-value argument. To programmatically access the coverage results in addition to generating a code coverage report, invoke the runtests function with two output arguments. After the tests run, the first output contains the test results and the second output contains the coverage results.

[testResults,coverageResults] = runtests("SolverTest", ...
    "ReportCoverageFor","quadraticSolver.m")
Running SolverTest
...
Done SolverTest
__________

MATLAB code coverage report has been saved to:
 C:\Temp\tpf83a0edb_55fb_4039_84f8_230a01d5f591\index.html

testResults = 

  1×3 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   3 Passed, 0 Failed, 0 Incomplete.
   1.8685 seconds testing time.


coverageResults = 

  Result with properties:

        Filename: "C:\work\quadraticSolver.m"
    CreationDate: 16-May-2023 15:11:20

Coverage summary (use generateHTMLReport to generate an HTML report):
   Function: 1/1 (100%)
   Statement: 4/4 (100%)

Use coverageSummary to retrieve information from the coverage results.

Input Arguments

collapse all

Tests, specified as a string array, character vector, or cell array of character vectors. Use this argument to specify your test content. For example, you can specify a test file, a test class, a folder that contains test files, a package that contains test classes, or a project folder that contains test files.

Example: runtests("myTestFile.m")

Example: runtests(["myTestFile/test1" "myTestFile/test3"])

Example: runtests("mypackage.MyTestClass")

Example: runtests(pwd)

Example: runtests({'mypackage.MyTestClass','myTestFile.m',pwd,'mypackage.subpackage'})

Example: runtests("C:\projects\project1")

Name-Value Arguments

Specify optional pairs of arguments as Name1=Value1,...,NameN=ValueN, where Name is the argument name and Value is the corresponding value. Name-value arguments must appear after other arguments, but the order of the pairs does not matter.

Example: results = runtests(tests,Name="productA_*") runs Test elements with a name that starts with "productA_".

Before R2021a, use commas to separate each name and value, and enclose Name in quotes.

Example: results = runtests(tests,"Name","productA_*") runs Test elements with a name that starts with "productA_".

Test Identification

collapse all

Whether to run tests in subfolders, specified as a numeric or logical 0 (false) or 1 (true). By default, the framework runs tests in the specified folders, but not in their subfolders.

Whether to run tests in subpackages, specified as a numeric or logical 0 (false) or 1 (true). By default, the framework runs tests in the specified packages, but not in their subpackages.

Whether to include tests from referenced projects, specified as a numeric or logical 0 (false) or 1 (true). For more information on referenced projects, see Componentize Large Projects.

Action to take against an invalid test file in a folder or package that the function is processing, specified as "warn" or "error".

  • "warn" — The function issues a warning for each invalid test file in a folder or package and runs the tests in the valid files.

  • "error" — The function throws an error if it finds an invalid test file in a folder or package.

An invalid test file is a test file that the framework cannot run. Examples include a test file that contains syntax errors, a function-based test file that is missing local functions, and a file with a Test method that is passed an undefined parameterization property.

Test Filtering

collapse all

Name of the base folder that contains the test file, specified as a string array, character vector, or cell array of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the Test element must be contained in one of the base folders specified by BaseFolder. If none of the Test elements match a base folder, an empty test suite is returned. Use the wildcard character (*) to match any number of characters. Use the question mark character (?) to match a single character.

For test files defined in packages, the base folder is the parent of the top-level package folder.

Names of the files and folders that contain source code, specified as a string vector, character vector, or cell vector of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the file that defines the test must depend on the specified source code. If none of the test files depend on the source code, an empty test suite is returned.

The specified value must represent at least one existing file with a .m, .p, .mlx, .mlapp, .mat, or .slx extension. You cannot explicitly specify a filename with an unsupported extension. If you specify a folder name, the framework extracts the paths to the supported files within the folder.

You must have a MATLAB® Test™ license to use DependsOn. For more information about selecting tests by source code dependency, see matlabtest.selectors.DependsOn (MATLAB Test).

Example: DependsOn=["myFile.m" "myFolder"]

Example: DependsOn=["folderA" "C:\work\folderB"]

Name of the test, specified as a string array, character vector, or cell array of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the Name property of the Test element must match one of the names specified by Name. If none of the Test elements have a matching name, an empty test suite is returned. Use the wildcard character (*) to match any number of characters. Use the question mark character (?) to match a single character.

For a given test file, the name of a test uniquely identifies the smallest runnable portion of the test content. The test name includes the package name, filename (excluding the extension), procedure name, and information about parameterization.

Name of a test class property that defines a parameter used by the test, specified as a string array, character vector, or cell array of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the Parameterization property of the Test element must contain at least one of the property names specified by ParameterProperty. If none of the Test elements have a matching property name, an empty test suite is returned. Use the wildcard character (*) to match any number of characters. Use the question mark character (?) to match to a single character.

Name of a parameter used by the test, specified as a string array, character vector, or cell array of character vectors. MATLAB generates parameter names based on the test class property that defines the parameters:

  • If the property value is a cell array, MATLAB generates parameter names from the elements of the cell array by taking into account their values, types, and dimensions.

  • If the property value is a structure, MATLAB generates parameter names from the structure fields.

The ParameterName argument filters the test suite. For the testing framework to include a test in the filtered suite, the Parameterization property of the Test element must contain at least one of the parameter names specified by ParameterName. If none of the Test elements have a matching parameter name, an empty test suite is returned. Use the wildcard character (*) to match any number of characters. Use the question mark character (?) to match a single character.

Name of the test procedure, specified as a string array, character vector, or cell array of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the ProcedureName property of the Test element must match one of the procedure names specified by ProcedureName. If none of the Test elements have a matching procedure name, an empty test suite is returned. Use the wildcard character (*) to match any number of characters. Use the question mark character (?) to match a single character.

In a class-based test, the name of a test procedure is the name of a Test method that contains the test. In a function-based test, it is the name of a local function that contains the test. In a script-based test, it is a name generated from the test section title. Unlike the name of a test suite element, the name of a test procedure does not include any package name, filename, or information about parameterization.

Name of the class that the test class derives from, specified as a string array, character vector, or cell array of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the TestClass property of the Test element must point to a test class that derives from one of the classes specified by Superclass. If none of the Test elements match a class, an empty test suite is returned.

Name of a tag used by the test, specified as a string array, character vector, or cell array of character vectors. This argument filters the test suite. For the testing framework to include a test in the filtered suite, the Tags property of the Test element must contain at least one of the tag names specified by Tag. If none of the Test elements have a matching tag name, an empty test suite is returned. Use the wildcard character (*) to match any number of characters. Use the question mark character (?) to match a single character.

Test Run Customization

collapse all

Whether to apply strict checks when running tests, specified as a numeric or logical 0 (false) or 1 (true). For example, the framework generates a qualification failure if a test issues a warning.

Whether to run tests in parallel, specified as a numeric or logical 0 (false) or 1 (true).

By default, runtests runs tests in serial. If you specify UseParallel as true, then runtests divides the test suite into groups and runs the groups in parallel if:

  • Parallel Computing Toolbox is installed.

  • An open parallel pool exists or automatic pool creation is enabled in the Parallel Preferences.

Otherwise, runtests runs tests in serial regardless of the value of UseParallel.

Testing in parallel might not be compatible with other options. For example, testing occurs in serial if UseParallel and Debug are both specified as true. When running test in parallel, the testing framework might vary the order and number of groups or which tests it includes in each group.

Whether to apply debugging capabilities when running tests, specified as a numeric or logical 0 (false) or 1 (true). For example, if a test failure occurs, the framework pauses test execution to enter debug mode.

Display level for event details, specified as an integer value from 0 through 4, or as a matlab.automation.Verbosity enumeration object. Integer values correspond to the members of the matlab.automation.Verbosity enumeration.

The runtests function displays failing and logged events with the amount of detail specified by OutputDetail. By default, runtests displays failing and logged events at the matlab.automation.Verbosity.Detailed level (level 3) and test run progress at the matlab.automation.Verbosity.Concise level (level 2).

Numeric RepresentationEnumeration Member NameVerbosity Description
0None

No information

1Terse

Minimal information

2Concise

Moderate amount of information

3Detailed

Some supplemental information

4Verbose

Lots of supplemental information

Maximum verbosity level for logged diagnostics included for the test run, specified as an integer value from 0 through 4, or as a matlab.automation.Verbosity enumeration object. The runtests function includes diagnostics that are logged at this level and below. Integer values correspond to the members of the matlab.automation.Verbosity enumeration.

By default, runtests includes diagnostics logged at the matlab.automation.Verbosity.Terse level (level 1). To exclude logged diagnostics, specify LoggingLevel as Verbosity.None (level 0).

Logged diagnostics are diagnostics that you supply to the testing framework with a call to the log (TestCase) or log (Fixture) method.

Numeric RepresentationEnumeration Member NameVerbosity Description
0None

No information

1Terse

Minimal information

2Concise

Moderate amount of information

3Detailed

Some supplemental information

4Verbose

Lots of supplemental information

Artifact Generation

collapse all

Names of source files and folders for code coverage analysis, specified as a string array, character vector, or cell array of character vectors. If you specify relative paths, the paths must be in the current folder. Otherwise, you must specify full paths. You can specify the paths to folders or to files that have a .m, .mlx, or .mlapp extension.

When you specify this argument, the function runs your tests and generates an HTML code coverage report for the specified source code. The report shows the parts of the source code that were executed by the tests. If you specify the coverageResults output argument (since R2023b) in addition to ReportCoverageFor, then the function provides programmatic access to coverage results in addition to generating the HTML code coverage report.

Example: "ReportCoverageFor",pwd

Example: "ReportCoverageFor",["myFile.m" "myFolder"]

Example: "ReportCoverageFor",["folderA" "C:\work\folderB"]

Whether to create or update a MAT-file being used in a test with specific qualification methods, specified as a numeric or logical 0 (false) or 1 (true). You must have Simulink® Test installed to use GenerateBaselines.

When you specify this argument as true, your test must use at least one of these qualification methods of the sltest.TestCase (Simulink Test) class:

  • verifySignalsMatch (for example, testCase.verifySignalsMatch(actVal,"myBaseline.mat"))

  • assumeSignalsMatch

  • assertSignalsMatch

  • fatalAssertSignalsMatch

For more information, see Using MATLAB-Based Simulink Tests in the Test Manager (Simulink Test).

Output Arguments

collapse all

Test results, returned as a row vector of matlab.unittest.TestResult objects. Each element of the vector provides information about one of the tests that ran.

Since R2023b

Coverage results, returned as a column vector of matlab.coverage.Result objects. Each element of the vector provides information about one of the files in your source code that was covered by the tests.

Use this argument with the ReportCoverageFor name-value argument to programmatically access the results of code coverage analysis for your source code.

Tips

  • When you use shared test fixtures in your tests and specify the input to the runtests function as a string array or cell array of character vectors, the testing framework sorts the array to reduce shared fixture setup and teardown operations. As a result, the tests might run in an order that is different from the order of elements in the input array. For more information, see sortByFixtures.

  • When you run tests on a remote parallel pool (requires MATLAB Parallel Server™ and Parallel Computing Toolbox), MATLAB first copies the local folders containing your tests to the remote workers. To minimize the overhead associated with this step, make sure that these folders include only files that are relevant to your tests.

Extended Capabilities

Version History

Introduced in R2013b

expand all