Main Content

verifyFail

Class: matlab.unittest.qualifications.Verifiable
Namespace: matlab.unittest.qualifications

Produce unconditional verification failure

expand all in page

Syntax

verifyFail(testCase)
verifyFail(testCase,diagnostic)

Description

verifyFail(testCase) produces an unconditional verification failure.

example

verifyFail(testCase,diagnostic) also associates the diagnostic information in diagnostic with the qualification.

example

Input Arguments

expand all

Test case, specified as a matlab.unittest.qualifications.Verifiable object. Because the matlab.unittest.TestCase class subclasses matlab.unittest.qualifications.Verifiable and inherits its methods, testCase is typically a matlab.unittest.TestCase object.

Diagnostic information to display when the qualification passes or fails, specified as a string array, character array, function handle, or array of matlab.automation.diagnostics.Diagnostic objects.

Depending on the test runner configuration, the testing framework can display diagnostics when the qualification passes or fails. By default, the framework displays diagnostics only when the qualification fails. You can override the default behavior by customizing the test runner. For example, use a DiagnosticsOutputPlugin instance to display both failing and passing event diagnostics.

Example: "My Custom Diagnostic"

Example: @dir

Attributes

Sealedtrue

To learn about attributes of methods, see Method Attributes.

Examples

expand all

Open Script

If you cannot write all the tests required for a new feature, use unconditional test failures as placeholders for the unimplemented tests. The failures remind you of the tests that need to be developed for your feature.

In a file in your current folder, create the FeatureTest class. Use the verifyFail method to add two placeholders to test your new feature.

classdef FeatureTest < matlab.unittest.TestCase
    methods (Test)
        function defaultBehavior(testCase)
            testCase.verifyFail
        end
        function otherBehavior(testCase)
            testCase.verifyFail("Add code to test nondefault behavior.")
        end
    end
end

If you run the tests, they both fail unconditionally.

runtests("FeatureTest")

Running FeatureTest

================================================================================
Verification failed in FeatureTest/defaultBehavior.
    ------------------
    Stack Information:
    ------------------
    In C:\work\FeatureTest.m (FeatureTest.defaultBehavior) at 4
================================================================================
.
================================================================================
Verification failed in FeatureTest/otherBehavior.
    ----------------
    Test Diagnostic:
    ----------------
    Add code to test nondefault behavior.
    ------------------
    Stack Information:
    ------------------
    In C:\work\FeatureTest.m (FeatureTest.otherBehavior) at 7
================================================================================
.
Done FeatureTest
__________

Failure Summary:

     Name                         Failed  Incomplete  Reason(s)
    ==========================================================================
     FeatureTest/defaultBehavior    X                 Failed by verification.
    --------------------------------------------------------------------------
     FeatureTest/otherBehavior      X                 Failed by verification.

ans = 

  1×2 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   0 Passed, 2 Failed, 0 Incomplete.
   0.087462 seconds testing time.
Open Script

You can use verifyFail to make sure that a piece of code does not run in certain conditions. For example, by placing a call to verifyFail within a callback method, an undesired attempt to run the callback results in a verification failure.

In a file in your current folder, create a handle class with an event.

classdef MyHandle < handle
    events
        SomethingHappened
    end
end

In your current folder, create the ListenerTest class. Add code to create an event source, a listener for the event, and a helper method that serves as the listener callback. Then, add two Test methods to test callback behavior when the event is triggered.

classdef ListenerTest < matlab.unittest.TestCase
    properties
        Source
        Listener
    end

    methods (TestMethodSetup)
        function setup(testCase)
            % Create the event source
            testCase.Source = MyHandle;
            % Add a listener to test execution of the callback code
            testCase.Listener = testCase.Source.addlistener( ...
                "SomethingHappened",@testCase.forbiddenCallback);
            % Remove the listener after the test
            testCase.addTeardown(@delete,testCase.Listener)
        end
    end

    methods (Test)
        function passingTest(testCase)
            % Disable the listener
            testCase.Listener.Enabled = false;
            testCase.Source.notify("SomethingHappened")   % Callback does not run
        end
        function failingTest(testCase)
            % The listener is enabled by default
            testCase.Source.notify("SomethingHappened")   % Callback runs
        end
    end

    methods
        function forbiddenCallback(testCase,~,~)
            % Test fails unconditionally
            testCase.verifyFail("This callback must not run!")
        end
    end
end

Run the tests. passingTest disables the listener and then triggers the event. Therefore, the callback does not run, and the test passes. However, when failingTest triggers the event, forbiddenCallback runs, resulting in a failure that is produced by verifyFail.

runtests("ListenerTest")

Running ListenerTest
.
================================================================================
Verification failed in ListenerTest/failingTest.
    ----------------
    Test Diagnostic:
    ----------------
    This callback must not run!
    ------------------
    Stack Information:
    ------------------
    In C:\work\ListenerTest.m (ListenerTest.forbiddenCallback) at 34
    In C:\work\ListenerTest.m (@(varargin)testCase.forbiddenCallback(varargin{:})) at 13
    In C:\work\ListenerTest.m (ListenerTest.failingTest) at 27
================================================================================
.
Done ListenerTest
__________

Failure Summary:

     Name                      Failed  Incomplete  Reason(s)
    =======================================================================
     ListenerTest/failingTest    X                 Failed by verification.

ans = 

  1×2 TestResult array with properties:

    Name
    Passed
    Failed
    Incomplete
    Duration
    Details

Totals:
   1 Passed, 1 Failed, 0 Incomplete.
   0.20956 seconds testing time.

Tips

  • Use verification qualifications to produce and record failures without throwing an exception. Because verifications do not throw exceptions, all test content runs to completion even when verification failures occur. Typically, verifications are the primary qualification for a unit test because they typically do not require an early exit from the test. Use other qualification types to test for violation of preconditions or incorrect test setup:

    • Use assumption qualifications to ensure that the test environment meets preconditions that otherwise do not result in a test failure. Assumption failures result in filtered tests, and the testing framework marks the tests as Incomplete. For more information, see matlab.unittest.qualifications.Assumable.

    • Use assertion qualifications when the failure condition invalidates the remainder of the current test content but does not prevent proper execution of subsequent tests. A failure at the assertion point renders the current test as Failed and Incomplete. For more information, see matlab.unittest.qualifications.Assertable.

    • Use fatal assertion qualifications to abort the test session upon failure. These qualifications are useful when the failure is so fundamental that continuing testing does not make sense. Fatal assertion qualifications are also useful when fixture teardown does not restore the environment state correctly, and aborting testing and starting a fresh session is preferable. For more information, see matlab.unittest.qualifications.FatalAssertable.

Version History

Introduced in R2013a

See Also

Topics