Effectively testing Qt 5 using Squish CocoSébastien Fricker and Amanda Burma09/18/2012 |
With more than tree million lines of code, Qt 5 is one of the largest open source projects. Creating a challenge for every contributing developer. In fact how can we be sure:
The approach to expect unit testing by a developer and letting the maintainer or approver take responsibility when integrating an extension, can be vastly improved by Squish Coco as it:
Squish Coco is available in two editions:
To install first sign up for an evaluation or permanent license:
This article only uses Squish Coco’s command line tools, allowing either edition to be used.
After installing Squish Coco modify the path variable to access
csg++
, the Squish Coco compiler replacement, from the command line.
Qt 5 depends of an important set of libraries. A full description of the requirements can be found on Qt homepage: http://qt-project.org/wiki/Building_Qt_5_from_Git
The system variable $WORK
refers to the working directory.
$QT5
is the Qt 5 source check out location. And
$PROCESSORS
indicates the number of available CPU cores.
|
The section (above) downloads the complete Qt 5 source.
Qt 5 provides a command line switch called -testcocoon
, which permits the instrumentation of Squish CocoṀore precisely:
csg++
instead of g++
for code generation.
Execute the following to compile:
|
At this stage, QtBase is generated along with $QT5BASE/lib
for each generated
shared library a file with the extension .csmes
is produced.
This file contains the code coverage instrumentation, and upon completion also contains
the code coverage report for each unit test.
Perform the following to execute the test suite: 1
|
Now, as each test executes, the instrumentation files in $QT5BASE/lib
are not updated,
however import the unit test results.
The following suppresses all coverage reports from the uic
, moc
and rcc
tools:
|
The following imports the execution report (.csexe
file) for each unit test into the instrumentation database (.csmes
file):
|
cmcsexeimport performs the import operation. After which the imported execution report is no longer needed, and can be safely removed.
At this stage an instrumentation database exists for each unit test, which contains the code coverage information for each execution. The following retrieves and places this information into the Qt 5 libraries’ instrumentation databases:
|
cmmerge imports the unit test results into Qt 5 library’s database. It also ignores the code coverage in the test code. After this operation, the instrumentation database for each unit test is no longer needed.
The following generates an HTML report from the code coverage database:
|
In $QT5BASE/lib
an HTML report is generated for each Qt library, making it possible
to analyze which source code line was not covered by the test
suite.
Having a code coverage report of Qt 5 in its entirety does not have any real value for a Qt developer: The developer is only focused on developing a feature or fixing a bug and does not need to be aware of the quality of the entire Qt project. Instead, the developer needs to know how the modification can negatively impact the project and how well the changes are tested.
The following example demonstrates how Squish Coco can be used to better understand the
impact of a change and the required testing:
To support the € symbol when converting a Unicode string to a Latin-1 codec, the
€ (unicode 0x20AC) will be converted to the character ’E
’.
Modify
QLatin1Codec::convertFromUnicode
as follows (modifications are underlined):
|
Before generating the Qt library, make a copy of the current instrumentation database as follows:
|
Then run make to compile. $QT5BASE/lib/libQtCore.so.5.0.0.csmes
is updated at the same time as
$QT5BASE/lib/libQtCore.so.5.0.0.so
.
No tests are executed at this stage; however Squish Coco can analyze which test is impacted by the modification:
|
euro_sym.html
report is the coverage report for the modified functions, and in our case only the
QLatin1Codec::convertFromUnicode
function.
The list of executions is limited to two entries:
tst_QString
with 78% coverage
tst_QTextStream
with 64% coverage
These are the only tests impacted by the modification, meaning all other tests are irrelevant. The report (above) also illustrates this function is not fully covered by the test suite, leaving the following as our potential regressions:
The two missing unit tests are illustrated below: one for testing the € symbol conversion, and one for testing other Unicode values.
Modify $QT5BASE/tests/auto/corelib/tools/qstring/tst_qstring.cpp
and define two new slots:
|
The slot code is:
|
Run the test suite again:
|
Following the test suite execution, the code coverage report contains the modification:
|
$WORK/euro_sym.html
is generated, displaying the code coverage result for the modification.
The modification’s coverage is 94%:
The only line not covered corresponds to the missing test for selecting the replacement character:
Using Squish Coco it is possible to reduce the code coverage analysis to only what the contributor and the approver needs:
Of course, such analysis should be made by the integration server and performed on all Qt modules, integrated with the code review tool; however, this is topic for another day…
In order to help the Qt community to improve the quality, froglogic GmbH publish now
code coverage statistics of QtBase computed on the daily snapshot.
Once the official Qt5 will be available, we will also provide the code coverage
analysis on the modifications between the actual snapshot and the last stable
release.
Here the link: http://download.froglogic.com/public/qt5-squishcoco-report
The following script was tested on Debian and performs the steps described in this article automatically.
To execute:
qt5-coco.sh
and qt5-euro.patch
into a folder.
./qt5-coco.sh
$HOME/coco