Qt Test Übersicht
Qt Test ist ein Framework für Unit-Tests von Qt-basierten Anwendungen und Bibliotheken. Qt Test bietet alle Funktionen, die in Unit-Test-Frameworks üblich sind, sowie Erweiterungen für das Testen von grafischen Benutzeroberflächen.
Qt Test wurde entwickelt, um das Schreiben von Unit-Tests für Qt-basierte Anwendungen und Bibliotheken zu erleichtern:
Feature | Einzelheiten |
---|---|
Geringes Gewicht | Qt Test besteht aus etwa 6000 Zeilen Code und 60 exportierten Symbolen. |
Eigenständig | Qt Test benötigt nur wenige Symbole aus dem Qt Core Modul für Nicht-Gui-Tests. |
Schnelles Testen | Qt Test benötigt keine speziellen Test-Runner; keine spezielle Registrierung für Tests. |
Datengesteuertes Testen | Ein Test kann mehrfach mit unterschiedlichen Testdaten ausgeführt werden. |
Grundlegende GUI-Tests | Qt Test bietet Funktionalität für Maus- und Tastatursimulation. |
Benchmarking | Qt Test unterstützt Benchmarking und bietet verschiedene Mess-Backends. |
IDE-freundlich | Qt Test gibt Meldungen aus, die von Qt Creator, Visual Studio und KDevelop interpretiert werden können. |
Thread-Sicherheit | Die Fehlerberichterstattung ist thread-sicher und atomar. |
Typsicherheit | Die umfangreiche Verwendung von Templates verhindert Fehler, die durch implizites Type-Casting entstehen. |
Leicht erweiterbar | Benutzerdefinierte Typen können leicht zu den Testdaten und der Testausgabe hinzugefügt werden. |
Sie können einen Qt Creator Assistenten verwenden, um ein Projekt zu erstellen, das Qt Tests enthält, und diese direkt von Qt Creator aus erstellen und ausführen. Weitere Informationen finden Sie unter Qt Creator: Tests erstellen und ausführen.
Einen Test erstellen
Um einen Test zu erstellen, untergliedern Sie die Klasse QObject und fügen Sie ihr einen oder mehrere private Slots hinzu. Jeder private Slot ist eine Testfunktion in Ihrem Test. QTest::qExec() kann verwendet werden, um alle Testfunktionen im Testobjekt auszuführen.
Darüber hinaus können Sie die folgenden privaten Slots definieren, die nicht als Testfunktionen behandelt werden. Wenn sie vorhanden sind, werden sie vom Testframework ausgeführt und können zur Initialisierung und Bereinigung entweder des gesamten Tests oder der aktuellen Testfunktion verwendet werden.
initTestCase()
wird aufgerufen, bevor die erste Testfunktion ausgeführt wird.initTestCase_data()
wird aufgerufen, um eine globale Testdatentabelle zu erstellen.cleanupTestCase()
wird aufgerufen, nachdem die letzte Testfunktion ausgeführt wurde.init()
wird vor der Ausführung jeder Testfunktion aufgerufen.cleanup()
wird nach jeder Testfunktion aufgerufen.
Verwenden Sie initTestCase()
, um den Test vorzubereiten. Jeder Test sollte das System in einem brauchbaren Zustand zurücklassen, so dass er wiederholt ausgeführt werden kann. Aufräumarbeiten sollten in cleanupTestCase()
behandelt werden, damit sie auch dann ausgeführt werden, wenn der Test fehlschlägt.
Verwenden Sie init()
für die Vorbereitung einer Testfunktion. Jede Testfunktion sollte das System in einem brauchbaren Zustand hinterlassen, so dass sie wiederholt ausgeführt werden kann. Aufräumarbeiten sollten in cleanup()
behandelt werden, damit sie auch dann ausgeführt werden, wenn die Testfunktion fehlschlägt und vorzeitig beendet wird.
Alternativ können Sie RAII (Resource Acquisition is Initialization) verwenden, wobei die Aufräumarbeiten in Destruktoren aufgerufen werden, um sicherzustellen, dass sie ausgeführt werden, wenn die Testfunktion zurückkehrt und das Objekt den Gültigkeitsbereich verlässt.
Wenn initTestCase()
fehlschlägt, wird keine Testfunktion ausgeführt. Wenn init()
fehlschlägt, wird die folgende Testfunktion nicht ausgeführt, sondern der Test wird mit der nächsten Testfunktion fortgesetzt.
Beispiel:
class MyFirstTest: public QObject { Q_OBJECTprivate: bool myCondition() { return true; }private slots: void initTestCase() { qDebug("Called before everything else."); } void myFirstTest() { QVERIFY(true); // prüfen, ob eine Bedingung erfüllt istQCOMPARE(1, 1); // zwei Werte vergleichen} void mySecondTest() { QVERIFY(myCondition()); QVERIFY(1 != 2); } void cleanupTestCase() { qDebug("Called after myFirstTest and mySecondTest."); } };
Wenn die Testklasse eine statische öffentliche Methode void initMain()
hat, wird diese von den Makros QTEST_MAIN aufgerufen, bevor das Objekt QApplication instanziiert wird. Dies wurde in 5.14 hinzugefügt.
Weitere Beispiele finden Sie im Qt Test Tutorial.
Erhöhen der Zeitüberschreitung für Testfunktionen
QtTest begrenzt die Laufzeit der einzelnen Tests, um Endlosschleifen und ähnliche Fehler zu erkennen. Standardmäßig wird jeder Aufruf einer Testfunktion nach fünf Minuten unterbrochen. Bei datengesteuerten Tests gilt dies für jeden Aufruf mit einem bestimmten Daten-Tag. Diese Zeitüberschreitung kann konfiguriert werden, indem die Umgebungsvariable QTEST_FUNCTION_TIMEOUT
auf die maximale Anzahl von Millisekunden gesetzt wird, die für einen einzelnen Aufruf akzeptabel ist. Wenn ein Test länger als die konfigurierte Zeitspanne dauert, wird er unterbrochen und qFatal()
aufgerufen. Infolgedessen bricht der Test standardmäßig ab, als ob er abgestürzt wäre.
Um QTEST_FUNCTION_TIMEOUT
über die Befehlszeile unter Linux oder macOS einzustellen, geben Sie ein:
QTEST_FUNCTION_TIMEOUT=900000 export QTEST_FUNCTION_TIMEOUT
Unter Windows:
SET QTEST_FUNCTION_TIMEOUT=900000
Führen Sie dann den Test in dieser Umgebung aus.
Alternativ können Sie die Umgebungsvariable auch programmatisch im Testcode selbst setzen, zum Beispiel durch den Aufruf der speziellen Methode initMain() Ihrer Testklasse:
qputenv("QTEST_FUNCTION_TIMEOUT", "900000");
Um einen geeigneten Wert für die Zeitüberschreitung zu berechnen, sehen Sie sich an, wie lange der Test normalerweise dauert, und entscheiden Sie, wie viel länger er dauern kann, ohne dass dies ein Symptom für ein Problem ist. Rechnen Sie diese längere Zeit in Millisekunden um, um den Timeout-Wert zu erhalten. Wenn Sie z. B. feststellen, dass ein Test, der mehrere Minuten dauert, auf einem langsamen Rechner bis zu zwanzig Minuten dauern kann, multiplizieren Sie 20 * 60 * 1000 = 1200000
und setzen Sie die Umgebungsvariable auf 1200000
statt auf den obigen Wert 900000
.
Einen Test erstellen
Sie können eine ausführbare Datei erstellen, die eine Testklasse enthält, die typischerweise eine Klasse des Produktionscodes testet. Normalerweise möchten Sie jedoch mehrere Klassen in einem Projekt mit einem einzigen Befehl testen.
Eine schrittweise Erklärung finden Sie unter Schreiben eines Unit-Tests.
Bauen mit CMake und CTest
Zum Erstellen eines Tests können Sie CMake und CTest verwenden. Mit CTest können Sie Tests auf der Grundlage eines regulären Ausdrucks, der mit dem Testnamen abgeglichen wird, ein- oder ausschließen. Außerdem können Sie die Eigenschaft LABELS
auf einen Test anwenden, und CTest kann dann Tests auf der Grundlage dieser Labels ein- oder ausschließen. Alle gekennzeichneten Ziele werden ausgeführt, wenn test
target in der Befehlszeile aufgerufen wird.
Hinweis: Wenn Sie unter Android nur ein Gerät oder einen Emulator angeschlossen haben, werden die Tests auf diesem Gerät ausgeführt. Wenn Sie mehr als ein Gerät angeschlossen haben, setzen Sie die Umgebungsvariable ANDROID_DEVICE_SERIAL
auf die ADB-Seriennummer des Geräts, auf dem Sie die Tests ausführen möchten.
CMake bietet noch einige andere Vorteile. Zum Beispiel kann das Ergebnis eines Testlaufs mit CDash praktisch ohne Aufwand auf einem Webserver veröffentlicht werden.
CTest skaliert auf sehr unterschiedliche Unit-Test-Frameworks und funktioniert mit QTest.
Nachfolgend ein Beispiel für eine CMakeLists.txt-Datei, die den Projektnamen und die verwendete Sprache (hier mytest und C++), die für die Erstellung des Tests erforderlichen Qt-Module (Qt5Test) und die im Test enthaltenen Dateien(tst_mytest.cpp) angibt.
project(mytest LANGUAGES CXX) find_package(Qt6 REQUIRED COMPONENTS Test) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) enable_testing(true) qt_add_executable(mytest tst_mytest.cpp) add_test(NAME mytest COMMAND mytest) target_link_libraries(mytest PRIVATE Qt::Test)
Weitere Informationen zu den Optionen, die Sie haben, finden Sie unter Erstellen mit CMake.
Bauen mit qmake
Wenn Sie qmake
als Build-Tool verwenden, fügen Sie einfach das Folgende zu Ihrer Projektdatei hinzu:
QT += testlib
Wenn Sie den Test über make check
ausführen möchten, fügen Sie die zusätzliche Zeile hinzu:
CONFIG += testcase
Um zu verhindern, dass der Test auf Ihrem Ziel installiert wird, fügen Sie die zusätzliche Zeile ein:
CONFIG += no_testcase_installs
Siehe das qmake-Handbuch für weitere Informationen über make check
.
Bauen mit anderen Werkzeugen
Wenn Sie andere Build-Tools verwenden, stellen Sie sicher, dass Sie den Ort der Qt Test Header-Dateien zu Ihrem Include-Pfad hinzufügen (normalerweise include/QtTest
unter Ihrem Qt-Installationsverzeichnis). Wenn Sie ein Release-Build von Qt verwenden, verlinken Sie Ihren Test mit der QtTest
Bibliothek. Für Debug-Builds verwenden Sie QtTest_debug
.
Qt Test Kommandozeilen-Argumente
Syntax
Die Syntax zur Ausführung eines Autotests hat die folgende einfache Form:
testname [options] [testfunctions[:testdata]]...
Ersetzen Sie testname
durch den Namen Ihrer ausführbaren Datei. testfunctions
kann Namen von Testfunktionen enthalten, die ausgeführt werden sollen. Wenn keine testfunctions
übergeben wird, werden alle Tests ausgeführt. Wenn Sie den Namen eines Eintrags in testdata
anhängen, wird die Testfunktion nur mit diesen Testdaten ausgeführt.
Zum Beispiel:
/myTestDirectory$ testQString toUpper
Führt die Testfunktion mit dem Namen toUpper
mit allen verfügbaren Testdaten aus.
/myTestDirectory$ testQString toUpper toInt:zero
Führt die Testfunktion toUpper
mit allen verfügbaren Testdaten und die Testfunktion toInt
mit der Testdatenzeile zero
aus (wenn die angegebenen Testdaten nicht vorhanden sind, schlägt der zugehörige Test fehl und die verfügbaren Daten-Tags werden gemeldet).
/myTestDirectory$ testMyWidget -vs -eventdelay 500
Führt den Funktionstest testMyWidget
aus, gibt jede Signalausgabe aus und wartet 500 Millisekunden nach jedem simulierten Maus-/Tastaturereignis.
Optionen
Optionen für die Protokollierung
Die folgenden Befehlszeilenoptionen bestimmen, wie die Testergebnisse protokolliert werden:
-o
Dateiname,Format
Writes output to the specified file, in the specified format (one oftxt
,csv
,junitxml
,xml
,lightxml
,teamcity
ortap
). Use the special filename-
(hyphen) to log to standard output.-o
Dateiname
Schreibt die Ausgabe in die angegebene Datei.-txt
Gibt die Ergebnisse als reinen Text aus.-csv
Gibt die Ergebnisse als kommagetrennte Werte (CSV) aus, die sich für den Import in Tabellenkalkulationen eignen. Dieser Modus ist nur für Benchmarks geeignet, da er normale Pass/Fail-Meldungen unterdrückt.-junitxml
Gibt die Ergebnisse als JUnit-XML-Dokument aus.-xml
Gibt die Ergebnisse als XML-Dokument aus.-lightxml
Gibt die Ergebnisse als Strom von XML-Tags aus.-teamcity
Gibt die Ergebnisse im TeamCity-Format aus.-tap
Gibt die Ergebnisse im Test Anything Protocol (TAP)-Format aus.
Die erste Version der Option -o
kann wiederholt werden, um Testergebnisse in mehreren Formaten zu protokollieren, aber es kann nicht mehr als eine Instanz dieser Option Testergebnisse auf der Standardausgabe protokollieren.
Wenn die erste Version der Option -o
verwendet wird, sollten weder die zweite Version der Option -o
noch die Optionen -txt
, -xml
, -lightxml
, -teamcity
, -junitxml
oder -tap
verwendet werden.
Wenn keine der beiden Versionen der Option -o
verwendet wird, werden die Testergebnisse auf der Standardausgabe protokolliert. Wenn keine Formatoption verwendet wird, werden die Testergebnisse im Klartext protokolliert.
Optionen für Testprotokolldetails
Die folgenden Befehlszeilenoptionen steuern, wie viele Details in den Testprotokollen angezeigt werden:
-silent
- Stille Ausgabe; zeigt nur schwerwiegende Fehler, Testabbrüche und minimale Statusmeldungen an.
-v1
Ausführliche Ausgabe; zeigt an, wann jede Testfunktion eingegeben wird. (Diese Option wirkt sich nur auf die reine Textausgabe aus.)-v2
Extended verbose output; shows each QCOMPARE() and QVERIFY(). (This option affects all output formats and implies-v1
for plain text output.)-vs
Zeigt alle Signale, die ausgegeben werden, und die aus diesen Signalen resultierenden Slot-Aufrufe. (Diese Option betrifft alle Ausgabeformate.)
Test-Optionen
Die folgenden Befehlszeilenoptionen beeinflussen die Ausführung von Tests:
-functions
- Gibt alle im Test verfügbaren Testfunktionen aus und bricht dann ab.
-datatags
Gibt alle im Test verfügbaren Daten-Tags aus. Einem globalen Daten-Tag wird ' __global__ ' vorangestellt.-eventdelay
ms
If no delay is specified for keyboard or mouse simulation (QTest::keyClick(), QTest::mouseClick() etc.), the value from this parameter (in milliseconds) is substituted.-keydelay
ms
Wie -eventdelay, beeinflusst aber nur die Tastatursimulation und nicht die Maussimulation.-mousedelay
ms
Wie -eventdelay, beeinflusst aber nur die Maussimulation und nicht die Tastatursimulation.-maxwarnings
number
Legt die maximale Anzahl der auszugebenden Warnungen fest. 0 für unbegrenzt, Standardwert ist 2000.-nocrashhandler
Deaktiviert den Crash-Handler auf Unix-Plattformen. Unter Windows wird der Windows-Fehlerberichtsdialog wieder aktiviert, der standardmäßig ausgeschaltet ist. Dies ist nützlich für die Fehlersuche bei Abstürzen.-repeat
n
Führen Sie die Testsuite n-mal aus oder bis der Test fehlschlägt. Nützlich, um fehlerhafte Tests zu finden. Bei einem negativen Ergebnis werden die Tests für immer wiederholt. Dies ist als Entwicklerwerkzeug gedacht und wird nur mit dem Klartext-Logger unterstützt.-skipblacklisted
Überspringen Sie die Tests auf der schwarzen Liste. Diese Option soll eine genauere Messung der Testabdeckung ermöglichen, indem verhindert wird, dass Tests auf der schwarzen Liste die Abdeckungsstatistik aufblähen. Wenn die Testabdeckung nicht gemessen wird, ist es empfehlenswert, Tests auf der schwarzen Liste auszuführen, um Änderungen in den Ergebnissen zu erkennen, z. B. einen neuen Absturz oder die Behebung des Problems, das die schwarze Liste verursacht hat.-platform
name
This command line argument applies to all Qt applications, but might be especially useful in the context of auto-testing. By using the "offscreen" platform plugin (-platform offscreen) it's possible to have tests that use QWidget or QWindow run without showing anything on the screen. Currently the offscreen platform plugin is only fully supported on X11.
Benchmarking-Optionen
Die folgenden Befehlszeilenoptionen steuern die Benchmark-Tests:
-callgrind
Verwendet Callgrind zur Zeitmessung von Benchmarks (nur Linux).-tickcounter
Verwendet CPU-Tick-Counter zur Zeitmessung von Benchmarks.-eventcounter
Zählt Ereignisse, die während Benchmarks empfangen werden.-minimumvalue
n
Legt den minimalen akzeptablen Messwert fest.-minimumtotal
n
Legt die minimale akzeptable Gesamtzahl für wiederholte Ausführungen einer Testfunktion fest.-iterations
n
Legt die Anzahl der Akkumulationsiterationen fest.-median
n
Legt die Anzahl der Median-Iterationen fest.-vb
Gibt ausführliche Benchmarking-Informationen aus.
Verschiedene Optionen
-help
Gibt die möglichen Kommandozeilenargumente aus und gibt einige nützliche Hilfestellungen.
Qt Test Umgebungsvariablen
Sie können bestimmte Umgebungsvariablen setzen, um die Ausführung eines Autotests zu beeinflussen:
QTEST_DISABLE_CORE_DUMP
- Wenn Sie diese Variable auf einen Wert ungleich Null setzen, wird die Erzeugung einer Core-Dump-Datei deaktiviert.
QTEST_DISABLE_STACK_DUMP
Wenn Sie diese Variable auf einen Wert ungleich Null setzen, verhindert Qt Test die Ausgabe eines Stacktraces, falls ein Autotest eine Zeitüberschreitung aufweist oder abstürzt.QTEST_FATAL_FAIL
Wenn Sie diese Variable auf einen Wert ungleich Null setzen, führt ein Fehler in einem Autotest zum sofortigen Abbruch des gesamten Autotests. Dies ist nützlich, um z.B. einen instabilen oder intermittierenden Fehler in einem Test zu debuggen, indem der Test in einem Debugger gestartet wird. Unterstützung für diese Variable wurde in Qt 6.1 hinzugefügt.QTEST_THROW_ON_FAIL
(seit 6.8)
Setting this variable to a non-zero value will cause QCOMPARE()/QVERIFY() etc to throw on failure (as opposed to just returning from the immediately-surrounding function scope).QTEST_THROW_ON_SKIP
(seit 6.8)
Same asQTEST_THROW_ON_FAIL
, except affecting QSKIP().
Erstellen einer Benchmark
Um einen Benchmark zu erstellen, befolgen Sie die Anweisungen zum Erstellen eines Tests und fügen dann ein QBENCHMARK Makro oder QTest::setBenchmarkResult() zu der Testfunktion hinzu, die Sie mit einem Benchmark vergleichen möchten. Im folgenden Codeschnipsel wird das Makro verwendet:
class MyFirstBenchmark: public QObject { Q_OBJECT private slots: void myFirstBenchmark() { QString string1; QString string2; QBENCHMARK { string1.localeAwareCompare(string2); } } };
Eine Testfunktion, die die Leistung misst, sollte entweder ein einziges QBENCHMARK
Makro oder einen einzigen Aufruf von setBenchmarkResult()
enthalten. Ein mehrfaches Auftreten ist nicht sinnvoll, da nur ein Leistungsergebnis pro Testfunktion oder pro Daten-Tag in einem datengesteuerten Setup gemeldet werden kann.
Vermeiden Sie es, den Testcode zu ändern, der den Körper eines QBENCHMARK
Makros bildet (oder beeinflusst), oder den Testcode, der den an setBenchmarkResult()
übergebenen Wert berechnet. Unterschiede in den aufeinanderfolgenden Leistungsergebnissen sollten idealerweise nur durch Änderungen an dem Produkt, das Sie testen, verursacht werden. Änderungen am Testcode können möglicherweise zu irreführenden Berichten über eine Leistungsänderung führen. Wenn Sie den Testcode ändern müssen, machen Sie dies in der Commit-Nachricht deutlich.
In einer Leistungstestfunktion sollte auf QBENCHMARK
oder setBenchmarkResult()
ein Verifizierungsschritt mit QCOMPARE(), QVERIFY() usw. folgen. Sie können dann ein Leistungsergebnis als ungültig kennzeichnen, wenn ein anderer Codepfad als der beabsichtigte gemessen wurde. Ein Leistungsanalysewerkzeug kann diese Informationen verwenden, um ungültige Ergebnisse herauszufiltern. Beispielsweise führt eine unerwartete Fehlerbedingung in der Regel dazu, dass das Programm vorzeitig aus der normalen Programmausführung aussteigt und somit fälschlicherweise eine dramatische Leistungssteigerung anzeigt.
Auswählen des Mess-Backends
Der Code innerhalb des QBENCHMARK-Makros wird gemessen und möglicherweise auch mehrmals wiederholt, um eine genaue Messung zu erhalten. Dies hängt von dem gewählten Mess-Backend ab. Es sind mehrere Back-Ends verfügbar. Sie können in der Befehlszeile ausgewählt werden:
Name | Befehlszeilen-Argument | Verfügbarkeit |
---|---|---|
Wandzeit | (Voreinstellung) | Alle Plattformen |
CPU-Tick-Zähler | -tickcounter | Windows, macOS, Linux, viele UNIX-ähnliche Systeme. |
Ereignis-Zähler | -eventcounter | Alle Plattformen |
Valgrind Callgrind | -callgrind | Linux (falls installiert) |
Linux Perf | -perf | Linux |
Kurz gesagt, Walltime ist immer verfügbar, erfordert aber viele Wiederholungen, um ein brauchbares Ergebnis zu erhalten. Tick-Counter sind in der Regel verfügbar und können Ergebnisse mit weniger Wiederholungen liefern, sind aber anfällig für Skalierungsprobleme der CPU-Frequenz. Valgrind liefert genaue Ergebnisse, berücksichtigt aber keine E/A-Wartezeiten und ist nur auf einer begrenzten Anzahl von Plattformen verfügbar. Die Ereigniszählung ist auf allen Plattformen verfügbar und liefert die Anzahl der Ereignisse, die von der Ereignisschleife empfangen wurden, bevor sie an die entsprechenden Ziele gesendet werden (dies kann auch Nicht-Qt-Ereignisse umfassen).
Die Linux-Performance-Monitoring-Lösung ist nur unter Linux verfügbar und bietet viele verschiedene Zähler, die durch Übergabe einer zusätzlichen Option -perfcounter countername
ausgewählt werden können, z. B. -perfcounter cache-misses
, -perfcounter branch-misses
oder -perfcounter l1d-load-misses
. Der Standardzähler ist cpu-cycles
. Die vollständige Liste der Zähler erhalten Sie, wenn Sie ein beliebiges Benchmark-Programm mit der Option -perfcounterlist
ausführen.
- Die Verwendung des Leistungszählers erfordert möglicherweise die Freigabe des Zugriffs für nicht privilegierte Anwendungen.
- Bei Geräten, die keine hochauflösenden Zeitgeber unterstützen, wird standardmäßig eine Granularität von einer Millisekunde verwendet.
Siehe Schreiben eines Benchmarks im Qt Test Tutorial für weitere Benchmarking-Beispiele.
Globale Testdaten verwenden
Sie können initTestCase_data()
definieren, um eine globale Testdatentabelle einzurichten. Jeder Test wird einmal für jede Zeile in der globalen Testdatentabelle ausgeführt. Wenn die Testfunktion selbst datengesteuert ist, wird sie für jede lokale Datenzeile und für jede globale Datenzeile ausgeführt. Wenn es also g
Zeilen in der globalen Datentabelle und d
Zeilen in der eigenen Datentabelle des Tests gibt, ist die Anzahl der Durchläufe dieses Tests g
mal d
.
Die globalen Daten werden mit dem Makro QFETCH_GLOBAL() aus der Tabelle geholt.
Im Folgenden werden typische Anwendungsfälle für globale Testdaten beschrieben:
- Auswahl unter den verfügbaren Datenbank-Backends in QSql-Tests, um jeden Test gegen jede Datenbank durchzuführen.
- Durchführen aller Netzwerktests mit und ohne SSL (HTTP versus HTTPS) und Proxying.
- Testen eines Timers mit einer hochgenauen Uhr und mit einer groben Uhr.
- Auswahl, ob ein Parser von einer QByteArray oder von einer QIODevice lesen soll.
Zum Beispiel, um jede von roundTripInt_data()
bereitgestellte Zahl mit jeder von initTestCase_data()
bereitgestellten Locale zu testen:
void TestQLocale::roundTripInt() { QFETCH_GLOBAL(QLocale, locale); QFETCH(int, number); bool ok; QCOMPARE(locale.toInt(locale.toString(number), &ok), number); QVERIFY(ok); }
In der Befehlszeile eines Tests können Sie den Namen einer Funktion (ohne den Präfix test-class-name) angeben, um nur die Tests dieser Funktion auszuführen. Wenn die Testklasse über globale Daten verfügt oder die Funktion datengesteuert ist, können Sie ein Daten-Tag nach einem Doppelpunkt anhängen, um nur den Datensatz dieses Tags für die Funktion auszuführen. Um sowohl ein globales Tag als auch ein für die Testfunktion spezifisches Tag anzugeben, kombinieren Sie beide mit einem Doppelpunkt dazwischen, wobei das globale Daten-Tag an erster Stelle steht. Zum Beispiel
./testqlocale roundTripInt:zero
führt den zero
Testfall des obigen roundTripInt()
Tests (unter der Annahme, dass seine TestQLocale
Klasse zu einer ausführbaren testqlocale
kompiliert wurde) in jeder der durch initTestCase_data()
angegebenen Sprachumgebungen aus, während
./testqlocale roundTripInt:C
alle drei Testfälle von roundTripInt()
nur in der C-Sprachumgebung ausführt und
./testqlocale roundTripInt:C:zero
führt nur den Testfall zero
in der Sprachumgebung C aus.
Eine solch fein abgestufte Kontrolle darüber, welche Tests ausgeführt werden sollen, kann die Fehlersuche erheblich erleichtern, da Sie nur den einen Testfall durchgehen müssen, bei dem ein Fehler aufgetreten ist.
© 2025 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.