Testing Qt slots and signals

Testing slots

Testing slots is very easy, because a slot is just a specially annotated method. You can call slots just like any other method you'd like to test, as shown below:

Example 25. QLabel test code, showing testing of a couple of slots

#include 
#include 
#include 
 
class testLabel: public QObject
{
    Q_OBJECT
private slots:
    void testChanges();
};
 
void testLabel::testChanges()
{
    QLabel label;
 
    // setNum() is a QLabel slot, but we can just call it like any
    // other method.
    label.setNum( 3 );
    QCOMPARE( label.text(), QString("3") );
 
    // clear() is also a slot.
    label.clear();
    QVERIFY( label.text().isEmpty() );
}
 
QTEST_MAIN(testLabel)
#include "tutorial5.moc"

Testing signals

Testing of signals is a little more difficult than testing of slots, however Qt offers a very useful class called QSignalSpy that helps a lot.

QSignalSpy is a class provided with Qt that allows you to record the signals that have been emitted from a particular QObject subclass object. You can then check that the right number of signals have been emitted, and that the right kind of signals were emitted. You can find more information on the QSignalSpy class in your Qt documentation.

An example of how you can use QSignalSpy to test a class that has signals is shown below.

Example 26. QCheckBox test code, showing testing of signals

#include 
#include 
#include 
 
class testCheckBox: public QObject
{
    Q_OBJECT
private slots:
    void testSignals();
};
 
void testCheckBox::testSignals()
{
    // You don't need to use an object created with "new" for
    // QSignalSpy, I just needed it in this case to test the emission
    // of a destroyed() signal.
    QCheckBox *xbox = new QCheckBox;
 
    // We are going to have two signal monitoring classes in use for
    // this test.
    // The first monitors the stateChanged() signal. 
    // Also note that QSignalSpy takes a pointer to the object.
    QSignalSpy stateSpy( xbox, SIGNAL( stateChanged(int) ) );
 
    // Not strictly necessary, but I like to check that I have set up
    // my QSignalSpy correctly.
    QVERIFY( stateSpy.isValid() );
 
    // Now we check to make sure we don't have any signals already
    QCOMPARE( stateSpy.count(), 0 );
 
    // Here is a second monitoring class - this one for the
    // destroyed() signal.
    QSignalSpy destroyedSpy( xbox, SIGNAL( destroyed() ) );
    QVERIFY( destroyedSpy.isValid() );
 
    // A sanity check to verify the initial state
    // This also shows that you can mix normal method checks with
    // signal checks.
    QCOMPARE( xbox->checkState(), Qt::Unchecked );
 
    // Shouldn't already have any signals
    QCOMPARE( destroyedSpy.count(), 0 );
 
    // If we change the state, we should get a signal.
    xbox->setCheckState( Qt::Checked );
    QCOMPARE( stateSpy.count(), 1 );
 
    xbox->setCheckState( Qt::Unchecked );
    QCOMPARE( stateSpy.count(), 2 );
 
    xbox->setCheckState( Qt::PartiallyChecked );
    QCOMPARE( stateSpy.count(), 3 );
 
    // If we destroy the object, the signal should be emitted.
    delete xbox;
 
    // So the count of objects should increase.
    QCOMPARE( destroyedSpy.count(), 1 );
 
    // We can also review the signals that we collected
    // QSignalSpy is really a QList of QLists, so we take the first
    // list, which corresponds to the arguments for the first signal
    // we caught.
    QList<QVariant> firstSignalArgs = stateSpy.takeFirst();
    // stateChanged() only has one argument - an enumerated type (int)
    // So we take that argument from the list, and turn it into an integer.
    int firstSignalState = firstSignalArgs.at(0).toInt();
    // We can then check we got the right kind of signal.
    QCOMPARE( firstSignalState, static_cast<int>(Qt::Checked) );
 
    // check the next signal - note that takeFirst() removes from the list
    QList<QVariant> nextSignalArgs = stateSpy.takeFirst();
    // this shows another way of fudging the argument types
    Qt::CheckState nextSignalState = (Qt::CheckState)nextSignalArgs.at(0).toInt();
    QCOMPARE( nextSignalState, Qt::Unchecked );
 
    // and again for the third signal
    nextSignalArgs = stateSpy.takeFirst();
    nextSignalState = (Qt::CheckState)nextSignalArgs.at(0).toInt();
    QCOMPARE( nextSignalState, Qt::PartiallyChecked );
}
 
QTEST_MAIN(testCheckBox)
#include "tutorial5a.moc"

The first 11 lines are essentially unchanged from previous examples that we've seen. Line 15 creates the object that will be tested - as noted in the comments in lines 12-14, the only reason that I'm creating it with new is because I need to delete it in line 45 to cause the destroyed() signal to be emitted.

Line 20 sets up the first of our two QSignalSpy instances. The one in line 20 monitors the stateChanged(int) signal, and the one in line 29 monitors the destroyed() signal. If you get the name or signature of the signal wrong (for example, if you use stateChanged() instead of stateChanged(int)), then this will not be caught at compile time, but will result in a runtime failure. You can test if things were set up correctly using the isValid(), as shown in lines 24 and 30.

As shown in line 34, there is no reason why you cannot test normal methods, signals and slots in the same test.

Line 38 changes the state of the object under test, which is supposed to result in a stateChanged(int) signal being emitted. Line 39 checks that the number of signals increases from zero to one. Lines 40 and 41 repeat the process, and again in lines 42 and 43.

Line 45 deletes the object under test, and line 47 tests that the destroyed() signal has been emitted.

For signals that have arguments (such as our stateChanged(int) signal), you may also wish to check that the arguments were correct. You can do this by looking at the list of signal arguments. Exactly how you do this is fairly flexible, however for simple tests like the one in the example, you can manually work through the list using takeFirst() and check that each argument is correct. This is shown in line 52, 55 and 57 for the first signal. The same approach is shown in lines 59, 61 and 62 for the second signal, and the in lines 64 to 66 for the third signal. For a more complex set of tests, you may wish to apply some data driven techniques.

Dica

Note: You should be aware that, for some class implementations, you may need to return control to the event loop to have signals emitted. If you need this, try using the QTest::qWait() function.