matlab.unittest.qualifications.Verifiable.verifyFail - Produce unconditional verification failure - MATLAB (original) (raw)

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

Produce unconditional verification failure

Syntax

Description

verifyFail([testCase](#bt00p80-1%5Fsep%5Fmw%5F8d5e73c7-bacb-46a7-a1c1-f24af91e6c03)) produces an unconditional verification failure.

example

verifyFail([testCase](#bt00p80-1%5Fsep%5Fmw%5F8d5e73c7-bacb-46a7-a1c1-f24af91e6c03),[diagnostic](#mw%5F8024b2f0-fdaa-49da-9967-9a16493ec805)) 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 amatlab.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

Examples

expand all

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.

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.

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.

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 asIncomplete. 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 asFailed 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