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.

General questions

How do I open a .chm file?in Ubuntu or linux??

sudo apt-get install  gnochm

sudo apt-get install kchmviewer

sudo aptitude install chm2pdf

MeeGo Dictionary

Maemo - a software platform developed by Nokia forsmartphones and Internet Tablets. It was initially based on theDebian Linux distribution. One of the predecessors of MeeGo, along with Moblin.

Maemo 5 - the default operating system on the Nokia N900, and current latest stable and independent version of Maemo. Based on the GTK toolkit. Aliases: Fremantle


MeeGo - an open source, Linux project which brings together the Moblin project, headed up by Intel, and Maemo, by Nokia, into a single open source activity. Managed by the Linux Foundation. The important thing to note that you end users will mostly be using an edition of MeeGo, MeeGo itself is not a single product (that’s why "will X run/get MeeGo" is a bad question), just like people are using a Linux distributions, not Linux (as in kernel) alone. 


MADDE - Maemo(/MeeGo) Application Development andDebugging Environment,
 offers the following features:

• Command-line cross-compiling
• Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
• Configurable for different targets & toolchains
• Client for the device to simplify the development process
• Will be used as part of future releases of the MeeGo SDK, along with QEMU, to enable cross-OS development.

MeegGo Handheld - MeeGo Core + MeeGo Touch Framework + Reference Handheld UX (not yet released).

MeeGo-Harmattan - the default operating system of the Nokia N9. Successor of Maemo 5, but based of the Qt toolkit. Originally named Maemo 6, but later rebranded as MeeGo-Harmattan (provisional name). It is MeeGo compatible (that is, has a MeeGo API) but is not to be confused with MeeGo 1.0 Handheld (as it is NOT based on MeeGo Core). MeeGo-Harmattan will not be released as a Nokia product for the N900. Aliases: Harmattan, Maemo 6.

MeeGo Touch Framework (MTF) - provides the features needed for developers creating applications for touch-enabled devices. Features include standardized window navigation, list and other widget behavior, and common theming for components.

MeeGo Web RunTime - Web Runtime (WRT) allows web developers to use standard web languages — HTML, CSS, and JavaScript — to create applications for mobile devices. WRT exposes the features of the underlying platform so that applications can interact with device data and combine location-based context with web information

Moblin - short for 'mobile Linux', is an open source operating system and application stack for Mobile Internet Devices (MIDs),netbooks, nettops and embedded devices. One of the predecessors of MeeGo, along with Maemo.

QML - a Declarative UI tool, in effect a markup language that defines UI elements and their behavior in a declarative manner, allowing, snappy, whizzy UIs. Present in Qt4.7+

Qt Quick - the Qt User Interface Creation Kit, which consists of QML, a specialized editor in QtCreator and all-around support for the declarative approach. Present in Qt4.7+. Aliases: Qt Declarative, Declarative UI, Bauhaus.


QtMobility - extends Qt with libraries providing additional features for applications targeting mobile platforms. These include the Service Framework and Contact and Bearer Management APIs, Messaging, Sensors, Camera, etc


UI Extensions for Mobile - an extension library for  Qt, which contains more than 50 UI elements tailored for mobile user experience. There is a proposal to use Orbit and Qt together withDirect UI as a replacement for the existing S60 'Avkon' set of UI elements in Symbian^4, but has been demonstrated to work on Maemo, too. It was previous known as Orbit before getting renamed to UI Extensions for Mobile (uiemo) and open sourced. Aliases: Uiemo, Orbit