TestCase QML Type

Test cases are written as JavaScript functions within a TestCase type:

import QtQuick 2.0
import QtTest 1.2

TestCase {
    name: "MathTests"

    function test_math() {
        compare(2 + 2, 4, "2 + 2 = 4")
    }

    function test_fail() {
        compare(2 + 2, 5, "2 + 2 = 5")
    }
}

Functions whose names start with "test_" are treated as test cases to be executed. The name property is used to prefix the functions in the output:

********* Start testing of MathTests *********
Config: Using QTest library 4.7.2, Qt 4.7.2
PASS   : MathTests::initTestCase()
FAIL!  : MathTests::test_fail() 2 + 2 = 5
   Actual (): 4
   Expected (): 5
   Loc: [/home/.../tst_math.qml(12)]
PASS   : MathTests::test_math()
PASS   : MathTests::cleanupTestCase()
Totals: 3 passed, 1 failed, 0 skipped
********* Finished testing of MathTests *********

Because of the way JavaScript properties work, the order in which the test functions are found is unpredictable. To assist with predictability, the test framework will sort the functions on ascending order of name. This can help when there are two tests that must be run in order.

Multiple TestCase types can be supplied. The test program will exit once they have all completed. If a test case doesn't need to run (because a precondition has failed), then optional can be set to true.

Table data can be provided to a test using a function name that ends with "_data". Alternatively, the init_data() function can be used to provide default test data for all test functions in a TestCase type:

import QtQuick 2.0
import QtTest 1.2

TestCase {
    name: "DataTests"

    function init_data() {
      return [
           {tag:"init_data_1", a:1, b:2, answer: 3},
           {tag:"init_data_2", a:2, b:4, answer: 6}
      ];
    }

    function test_table_data() {
        return [
            {tag: "2 + 2 = 4", a: 2, b: 2, answer: 4 },
            {tag: "2 + 6 = 8", a: 2, b: 6, answer: 8 },
        ]
    }

    function test_table(data) {
        //data comes from test_table_data
        compare(data.a + data.b, data.answer)
    }

    function test__default_table(data) {
        //data comes from init_data
        compare(data.a + data.b, data.answer)
    }
}

The test framework will iterate over all of the rows in the table and pass each row to the test function. As shown, the columns can be extracted for use in the test. The tag column is special - it is printed by the test framework when a row fails, to help the reader identify which case failed amongst a set of otherwise passing tests.

Functions whose names start with "benchmark_" will be run multiple times with the Qt benchmark framework, with an average timing value reported for the runs. This is equivalent to using the QBENCHMARK macro in the C++ version of QTestLib.

TestCase {
    id: top
    name: "CreateBenchmark"

    function benchmark_create_component() {
        var component = Qt.createComponent("item.qml")
        var obj = component.createObject(top)
        obj.destroy()
        component.destroy()
    }
}

RESULT : CreateBenchmark::benchmark_create_component:
     0.23 msecs per iteration (total: 60, iterations: 256)
PASS   : CreateBenchmark::benchmark_create_component()

To get the effect of the QBENCHMARK_ONCE macro, prefix the test function name with "benchmark_once_".

The keyPress(), keyRelease(), and keyClick() methods can be used to simulate keyboard events within unit tests. The events are delivered to the currently focused QML item. You can pass either a Qt.Key enum value or a latin1 char (string of length one)

Rectangle {
    width: 50; height: 50
    focus: true

    TestCase {
        name: "KeyClick"
        when: windowShown

        function test_key_click() {
            keyClick(Qt.Key_Left)
            keyClick("a")
            ...
        }
    }
}

The mousePress(), mouseRelease(), mouseClick(), mouseDoubleClick(), mouseDoubleClickSequence() and mouseMove() methods can be used to simulate mouse events in a similar fashion.

Note: keyboard and mouse events can only be delivered once the main window has been shown. Attempts to deliver events before then will fail. Use the when and windowShown properties to track when the main window has been shown.

A typical pattern with QML tests is to dynamically create an item and then destroy it at the end of the test function:

TestCase {
    id: testCase
    name: "MyTest"
    when: windowShown

    function test_click() {
        var item = Qt.createQmlObject("import QtQuick 2.0; Item {}", testCase);
        verify(item);

        // Test item...

        item.destroy();
    }
}

The problem with this pattern is that any failures in the test function will cause the call to item.destroy() to be skipped, leaving the item hanging around in the scene until the test case has finished. This can result in interference with future tests; for example, by blocking input events or producing unrelated debug output that makes it difficult to follow the code's execution.

By calling createTemporaryQmlObject() instead, the object is guaranteed to be destroyed at the end of the test function:

TestCase {
    id: testCase
    name: "MyTest"
    when: windowShown

    function test_click() {
        var item = createTemporaryQmlObject("import QtQuick 2.0; Item {}", testCase);
        verify(item);

        // Test item...

        // Don't need to worry about destroying "item" here.
    }
}

For objects that are created via the createObject() function of Component, the createTemporaryObject() function can be used.

See also SignalSpy, Qt Quick Test

This property will be set to true once the test case has completed execution. Test cases are only executed once. The initial value is false.

See Also▲

This property defines the name of the test case for result reporting. The default value is an empty string.

TestCase {
    name: "ButtonTests"
    ...
}

Multiple TestCase types can be supplied in a test application. The application will exit once they have all completed. If a test case does not need to run (because a precondition has failed), then this property can be set to true. The default value is false.

TestCase {
    when: false
    optional: true
    function test_not_run() {
        verify(false)
    }
}

See Also▲

This property will be set to true while the test case is running. The initial value is false, and the value will become false again once the test case completes.

See Also▲

This property should be set to true when the application wants the test cases to run. The default value is true. In the following example, a test is run when the user presses the mouse button:

Rectangle {
    id: foo
    width: 640; height: 480
    color: "cyan"

    MouseArea {
        id: area
        anchors.fill: parent
    }

    property bool bar: true

    TestCase {
        name: "ItemTests"
        when: area.pressed
        id: test1

        function test_bar() {
            verify(bar)
        }
    }
}

The test application will exit once all TestCase types have been triggered and have run. The optional property can be used to exclude a TestCase type.

See Also▲

This property will be set to true after the QML viewing window has been displayed. Normally test cases run as soon as the test application is loaded and before a window is displayed. If the test case involves visual types and behaviors, then it may need to be delayed until after the window is shown.

Button {
    id: button
    onClicked: text = "Clicked"
    TestCase {
        name: "ClickTest"
        when: windowShown
        function test_click() {
            button.clicked();
            compare(button.text, "Clicked");
        }
    }
}

This function is called after each test function that is executed in the TestCase type. The default implementation does nothing. The application can provide its own implementation to perform cleanup after each test function.

See Also▲

This function is called after all other test functions in the TestCase type have completed. The default implementation does nothing. The application can provide its own implementation to perform test case cleanup.

See Also▲

Fails the current test case if actual is not the same as expected, and displays the optional message. Similar to QCOMPARE(actual, expected) in C++.

See Also▲

This function dynamically creates a QML object from the given component with the specified optional parent and properties. The returned object will be destroyed (if it was not already) after cleanup() has finished executing, meaning that objects created with this function are guaranteed to be destroyed after each test, regardless of whether or not the tests fail.

If there was an error while creating the object, null will be returned.

This function calls component.createObject() internally.

This method was introduced in Qt 5.9.

See Also▲

This function dynamically creates a QML object from the given qml string with the specified parent. The returned object will be destroyed (if it was not already) after cleanup() has finished executing, meaning that objects created with this function are guaranteed to be destroyed after each test, regardless of whether or not the tests fail.

If there was an error while creating the object, null will be returned.

If filePath is specified, it will be used for error reporting for the created object.

This function calls Qt.createQmlObject() internally.

This method was introduced in Qt 5.9.

See Also▲

In a data-driven test, marks the row associated with tag as expected to fail. When the fail occurs, display the message, abort the test, and mark the test as passing. Similar to QEXPECT_FAIL(tag, message, Abort) in C++.

If the test is not data-driven, then tag must be set to an empty string.

See Also▲

In a data-driven test, marks the row associated with tag as expected to fail. When the fail occurs, display the message, and then continue the test. Similar to QEXPECT_FAIL(tag, message, Continue) in C++.

If the test is not data-driven, then tag must be set to an empty string.

See Also▲

Fails the current test case, with the optional message. Similar to QFAIL(message) in C++.

Returns the first child of parent with objectName, or null if no such item exists. Both visual and non-visual children are searched recursively, with visual children being searched first.

compare(findChild(item, "childObject"), expectedChildObject);

This method was introduced in Qt 5.4.

Fails the current test case if the difference betwen actual and expected is greater than delta, and displays the optional message. Similar to qFuzzyCompare(actual, expected) in C++ but with a required delta value.

This function can also be used for color