Qt Test Übersicht

Qt Test ist ein Framework für Unit-Tests von Qt-basierten Anwendungen und Bibliotheken. „ Qt Test “ bietet alle Funktionen, die üblicherweise in Unit-Test-Frameworks zu finden sind, sowie Erweiterungen zum Testen grafischer Benutzeroberflächen.

Qt Test wurde entwickelt, um das Schreiben von Unit-Tests für Qt-basierte Anwendungen und Bibliotheken zu vereinfachen:

Mit dem Assistenten „ Qt Creator “ können Sie ein Projekt mit Qt-Tests erstellen und diese direkt über „ Qt Creator “ kompilieren und ausführen. Weitere Informationen finden Sie unter Qt Creator: Tests kompilieren und ausführen.

Erstellen eines Tests

Um einen Test zu erstellen, erstellen Sie eine Unterklasse von ` QObject ` und fügen Sie ihr einen oder mehrere private Slots hinzu. Jeder private Slot ist eine Testfunktion in Ihrem Test. Mit ` QTest::qExec()` können alle Testfunktionen im Testobjekt ausgeführt werden.

Darüber hinaus können Sie die folgenden privaten Slots definieren, die nicht als Testfunktionen behandelt werden. Sind sie vorhanden, werden sie vom Test-Framework ausgeführt und können dazu verwendet werden, entweder den gesamten Test oder die aktuelle Testfunktion zu initialisieren und zu bereinigen.

• initTestCase() wird vor der Ausführung der ersten Testfunktion aufgerufen.
• initTestCase_data() wird aufgerufen, um eine globale Testdatentabelle anzulegen.
• 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() “ zur Vorbereitung des Tests. Jeder Test sollte das System in einem nutzbaren Zustand hinterlassen, damit es wiederholt ausgeführt werden kann. Bereinigungsvorgänge sollten in „ cleanupTestCase() “ abgewickelt werden, damit sie auch dann ausgeführt werden, wenn der Test fehlschlägt.

Verwenden Sie „ init() “ zur Vorbereitung einer Testfunktion. Jede Testfunktion sollte das System in einem nutzbaren Zustand hinterlassen, damit sie wiederholt ausgeführt werden kann. Aufräumvorgänge sollten in „ cleanup() “ abgewickelt 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, bei dem Bereinigungsvorgänge 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 nachfolgende Testfunktion nicht ausgeführt; der Test wird mit der nächsten Testfunktion fortgesetzt.

Beispiel:

class MyFirstTest: public QObject
{
    Q_OBJECT

private:
    bool myCondition()
    {
        return true;
    }

private slots:
    void initTestCase()
    {
        qDebug("Called before everything else.");
    }

    void myFirstTest()
    {
        QVERIFY(true); // Überprüfen, ob eine Bedingung erfüllt ist
        QCOMPARE(1, 1); // Zwei Werte vergleichen
    }

   void mySecondTest()
    {
        QVERIFY(myCondition());
        QVERIFY(1 != 2);
    }

    void cleanupTestCase()
    {
        qDebug("Called after myFirstTest and mySecondTest.");
    }
};

Wenn die Testklasse schließlich über eine statische öffentliche Methode „ void initMain() “ verfügt, wird diese von den Makros „ QTEST_MAIN “ aufgerufen, bevor das „ QApplication “-Objekt instanziiert wird. Diese Funktion wurde in Version 5.14 hinzugefügt.

Weitere Beispiele finden Sie im Tutorial zu „Qt Test “.

Erhöhen des Timeouts für Testfunktionen

QtTest begrenzt die Laufzeit jedes 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 eindeutigen Daten-Tag. Dieses Timeout lässt sich konfigurieren, indem die Umgebungsvariable „ QTEST_FUNCTION_TIMEOUT “ auf die maximale Anzahl an Millisekunden gesetzt wird, die für einen einzelnen Aufruf akzeptabel ist. Dauert ein Test länger als das konfigurierte Timeout, wird er unterbrochen und „ qFatal() “ aufgerufen. Infolgedessen wird der Test standardmäßig abgebrochen, als wäre er abgestürzt.

Um „ QTEST_FUNCTION_TIMEOUT “ unter Linux oder macOS über die Befehlszeile festzulegen, geben Sie Folgendes ein:

QTEST_FUNCTION_TIMEOUT=900000
export QTEST_FUNCTION_TIMEOUT

Unter Windows:

SET QTEST_FUNCTION_TIMEOUT=900000

Führen Sie den Test anschließend in dieser Umgebung durch.

Alternativ können Sie die Umgebungsvariable programmgesteuert im Testcode selbst setzen, beispielsweise durch Aufruf der speziellen Methode ` initMain() ` Ihrer Testklasse:

qputenv("QTEST_FUNCTION_TIMEOUT", "900000");

Um einen geeigneten Wert für das Timeout zu berechnen, ermitteln Sie, wie lange der Test normalerweise dauert, und legen Sie fest, wie viel länger er dauern darf, ohne dass dies auf ein Problem hindeutet. Rechnen Sie diese längere Zeit in Millisekunden um, um den Timeout-Wert zu erhalten. Wenn Sie beispielsweise festlegen, dass ein Test, der mehrere Minuten dauert, vernünftigerweise bis zu zwanzig Minuten dauern könnte – etwa auf einem langsamen Rechner –, multiplizieren Sie 20 * 60 * 1000 = 1200000 und setzen Sie die Umgebungsvariable auf 1200000 anstelle des oben genannten 900000.

Erstellen eines Tests

Sie können eine ausführbare Datei erstellen, die eine Testklasse enthält, die in der Regel eine Klasse des Produktionscodes testet. In der Regel möchten Sie jedoch mehrere Klassen in einem Projekt mit einem einzigen Befehl testen.

Eine Schritt-für-Schritt-Anleitung finden Sie unter „Erstellen eines Unit-Tests “.

Erstellen mit CMake und CTest

Sie können CMake und CTest verwenden, um einen Test zu erstellen. Mit CTest können Sie Tests anhand eines regulären Ausdrucks, der mit dem Testnamen abgeglichen wird, ein- oder ausschließen. Sie können einem Test zusätzlich die Eigenschaft „ LABELS “ zuweisen, woraufhin CTest Tests anhand dieser Bezeichnungen ein- oder ausschließen kann. Alle mit einer Bezeichnung versehenen Ziele werden ausgeführt, wenn das Ziel „ test “ über die Befehlszeile aufgerufen wird.

CMake bietet noch einige weitere Vorteile. So lässt sich beispielsweise das Ergebnis eines Testlaufs mit CDash nahezu mühelos auf einem Webserver veröffentlichen.

CTest lässt sich an sehr unterschiedliche Unit-Test-Frameworks anpassen und funktioniert sofort mit „ QTest “.

Im Folgenden finden Sie ein Beispiel für eine „CMakeLists.txt“-Datei, in der der Projektname und die verwendete Sprache (hier „mytest“ und „C++“), die für die Erstellung des Tests erforderlichen Qt-Module (Qt Test) sowie die im Test einbezogenen Dateien (tst_mytest.cpp) angegeben sind.

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 verfügbaren Optionen finden Sie unter „Erstellen mit CMake“.

Erstellen mit qmake

Wenn Sie „ qmake “ als Build-Tool verwenden, fügen Sie einfach Folgendes zu Ihrer Projektdatei hinzu:

QT += testlib

Wenn Sie den Test über make check ausführen möchten, fügen Sie die folgende Zeile hinzu:

CONFIG += testcase

Um zu verhindern, dass der Test auf Ihrem Zielsystem installiert wird, fügen Sie die folgende Zeile hinzu:

CONFIG += no_testcase_installs

Weitere Informationen zu ` make check` finden Sie im qmake-Handbuch.

Erstellen mit anderen Tools

Wenn Sie andere Build-Tools verwenden, stellen Sie sicher, dass Sie den Speicherort der Header-Dateien von „ Qt Test “ zu Ihrem Include-Pfad hinzufügen (in der Regel „ include/QtTest “ unter Ihrem Qt-Installationsverzeichnis). Wenn Sie eine Release-Version von Qt verwenden, verknüpfen Sie Ihren Test mit der Bibliothek „ QtTest “. Für Debug-Builds verwenden Sie „ QtTest_debug “.

Qt Test Befehlszeilenargumente

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 die Namen der auszuführenden Testfunktionen enthalten. Werden keine „ testfunctions “ übergeben, werden alle Tests ausgeführt. Wenn Sie den Namen eines Eintrags aus „ testdata “ anhängen, wird die Testfunktion nur mit diesen Testdaten ausgeführt.

Beispiel:

/myTestDirectory$ testQString toUpper

Führt die Testfunktion „ toUpper “ mit allen verfügbaren Testdaten aus.

/myTestDirectory$ testQString toUpper toInt:zero

Führt die Testfunktion „ toUpper “ mit allen verfügbaren Testdaten aus und die Testfunktion „ toInt “ mit der Testdatenzeile namens „ zero “ (falls 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 nach jedem simulierten Maus-/Tastaturereignis 500 Millisekunden.

Optionen

Protokollierungsoptionen

Die folgenden Befehlszeilenoptionen legen fest, wie Testergebnisse ausgegeben werden:

• -o Dateiname,Format
  Writes output to the specified file, in the specified format (one of txt, csv, junitxml, xml, lightxml, teamcity or tap). Use the special filename - (hyphen) to log to standard output.
• -o Dateiname
  Schreibt die Ausgabe in die angegebene Datei.
• -txt
  Gibt die Ergebnisse im Klartext aus.
• -csv
  Gibt die Ergebnisse als kommagetrennte Werte (CSV) aus, die für den Import in Tabellenkalkulationsprogramme geeignet sind. Dieser Modus eignet sich nur für Benchmarks, da er die üblichen Erfolgsmeldungen und Fehlermeldungen 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; es kann jedoch nicht mehr als eine Instanz dieser Option Testergebnisse an die Standardausgabe protokollieren.

Wird die erste Version der Option „ -o “ verwendet, 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 in die Standardausgabe geschrieben. Wenn keine Formatoption verwendet wird, werden die Testergebnisse im Klartext ausgegeben.

Optionen für detaillierte Testprotokolle

Die folgenden Befehlszeilenoptionen steuern, wie detailliert die Testprotokolle ausgegeben werden:

• -silent
  Stille Ausgabe; zeigt nur schwerwiegende Fehler, Testfehler und minimale Statusmeldungen an.
• -v1
  Ausführliche Ausgabe; zeigt an, wann jede Testfunktion aufgerufen wird. (Diese Option wirkt sich nur auf die Ausgabe im Klartext 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 ausgegebenen Signale und die daraus resultierenden Slot-Aufrufe an. (Diese Option wirkt sich auf alle Ausgabeformate aus.)

Testoptionen

Die folgenden Befehlszeilenoptionen beeinflussen die Art und Weise, wie Tests ausgeführt werden:

• -functions
  Gibt alle im Test verfügbaren Testfunktionen aus und beendet dann das Programm.
• -datatags
  Gibt alle im Test verfügbaren Daten-Tags aus. Ein globales Daten-Tag wird durch „__global__“ gekennzeichnet.
• -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, wirkt sich jedoch nur auf die Tastatursimulation und nicht auf die Maussimulation aus.
• -mousedelay ms
  Wie -eventdelay, wirkt sich jedoch nur auf die Maussimulation und nicht auf die Tastatursimulation aus.
• -maxwarnings Zahl
  Legt die maximale Anzahl der auszugebenden Warnungen fest. 0 für unbegrenzt, Standardwert ist 2000.
• -nocrashhandler
  Deaktiviert den Absturz-Handler auf Unix-Plattformen. Unter Windows wird dadurch der Windows-Fehlerberichtsdialog wieder aktiviert, der standardmäßig deaktiviert ist. Dies ist nützlich für die Fehlersuche bei Abstürzen.
• -repeat n
  Führt die Testsuite n-mal aus oder so lange, bis ein Test fehlschlägt. Nützlich zum Aufspüren unzuverlässiger Tests. Bei einem negativen Wert werden die Tests unendlich oft wiederholt. Dies ist als Entwicklerwerkzeug gedacht und wird nur vom Klartext-Logger unterstützt.
• -skipblacklisted
  Die auf der Blacklist stehenden Tests überspringen. Diese Option soll eine genauere Messung der Testabdeckung ermöglichen, indem verhindert wird, dass Tests auf der Blacklist die Abdeckungsstatistiken künstlich aufblähen. Wenn keine Testabdeckung gemessen wird, wird empfohlen, die auf der Blacklist stehenden Tests auszuführen, um etwaige Änderungen in ihren Ergebnissen aufzudecken, wie z. B. einen neuen Absturz oder die Behebung des Problems, das zur Aufnahme in die Blacklist geführt 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.

Optionen für das Benchmarking

Die folgenden Befehlszeilenoptionen steuern die Benchmark-Tests:

• -callgrind
  Verwendet Callgrind zur Zeitmessung bei Benchmarks (Linux und macOS).
• -perf
  Verwendet Linux-Perf-Ereignisse zur Zeitmessung bei Benchmarks
• -tickcounter
  Verwendet CPU-Tick-Zähler zur Zeitmessung bei Benchmarks. Erfordert Hardwareunterstützung.
• -eventcounter
  Zählt die während der Benchmark-Tests empfangenen Ereignisse.
• -minimumvalue n
  Legt den minimal zulässigen Messwert fest.
• -minimumtotal n
  Legt die minimal zulässige Gesamtanzahl 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 Informationen zum Benchmarking aus.

Verschiedene Optionen

• -help
  Gibt die möglichen Befehlszeilenargumente aus und bietet nützliche Hilfestellungen.

Qt Test Umgebungsvariablen

Sie können bestimmte Umgebungsvariablen setzen, um die Ausführung eines Autotests zu beeinflussen:

• QTEST_DISABLE_CORE_DUMP
  Wird diese Variable auf einen Wert ungleich Null gesetzt, wird die Erstellung einer Core-Dump-Datei deaktiviert.
• QTEST_DISABLE_STACK_DUMP
  Wird diese Variable auf einen Wert ungleich Null gesetzt, verhindert dies, dass Qt Test einen Stacktrace ausgibt, falls ein Autotest aufgrund einer Zeitüberschreitung abbricht oder abstürzt.
• QTEST_FATAL_FAIL
  Wird diese Variable auf einen Wert ungleich Null gesetzt, führt ein Fehler in einem Autotest dazu, dass der gesamte Autotest sofort abgebrochen wird. Dies ist beispielsweise nützlich, um einen instabilen oder sporadisch auftretenden Fehler in einem Test zu debuggen, indem der Test in einem Debugger gestartet wird. Die Unterstützung für diese Variable wurde in Qt 6.1 hinzugefügt.

Erstellen eines Benchmarks

Um einen Benchmark zu erstellen, befolgen Sie die Anweisungen zum Erstellen eines Tests und fügen Sie anschließend das Makro „ QBENCHMARK “ oder „ QTest::setBenchmarkResult()“ in die Testfunktion ein, die Sie benchmarken möchten. Im folgenden Codeausschnitt 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 einzelnes „ QBENCHMARK “-Makro oder einen einzelnen Aufruf von „ setBenchmarkResult() “ enthalten. Mehrere Vorkommen sind nicht sinnvoll, da pro Testfunktion bzw. pro Daten-Tag in einem datengesteuerten Setup nur ein Leistungsergebnis gemeldet werden kann.

Vermeiden Sie es, den Testcode zu ändern, der den Hauptteil eines „ QBENCHMARK “-Makros bildet (oder beeinflusst), oder den Testcode, der den an „ setBenchmarkResult() “ übergebenen Wert berechnet. Unterschiede in aufeinanderfolgenden Leistungsergebnissen sollten im Idealfall ausschließlich durch Änderungen am getesteten Produkt verursacht werden. Änderungen am Testcode können möglicherweise zu irreführenden Berichten über Leistungsänderungen führen. Falls Sie den Testcode ändern müssen, machen Sie dies in der Commit-Meldung deutlich.

In einer Leistungstestfunktion sollte auf „ QBENCHMARK “ oder „ setBenchmarkResult() “ ein Verifizierungsschritt folgen, bei dem „ QCOMPARE()“, „ QVERIFY()“ usw. verwendet werden. Sie können ein Leistungsergebnis dann als ungültig kennzeichnen, wenn ein anderer als der beabsichtigte Codepfad gemessen wurde. Ein Tool zur Leistungsanalyse kann diese Informationen nutzen, 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 drastische Leistungssteigerung anzeigt.

Auswahl 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 vom ausgewählten Mess-Backend ab. Es stehen mehrere Backends zur Verfügung. Sie können über die Befehlszeile ausgewählt werden (siehe Benchmarking-Optionen):

Kurz gesagt: Die Walltime ist zwar immer verfügbar, erfordert jedoch viele Wiederholungen, um ein aussagekräftiges Ergebnis zu erhalten. Tick-Zähler sind in der Regel verfügbar und liefern Ergebnisse mit weniger Wiederholungen, können jedoch anfällig für Probleme bei der CPU-Frequenzskalierung sein. Valgrind liefert exakte Ergebnisse, berücksichtigt jedoch 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 ihre entsprechenden Ziele weitergeleitet werden (dies kann auch Nicht-Qt-Ereignisse umfassen).

Die Linux-Leistungsüberwachungslö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, beispielsweise „ -perfcounter cache-misses “, „ -perfcounter branch-misses “ oder „ -perfcounter l1d-load-misses “. Der Standardzähler ist „ cpu-cycles “. Die vollständige Liste der Zähler erhält man, indem man eine beliebige Benchmark-Ausführungsdatei mit der Option „ -perfcounterlist “ ausführt.

• Die Verwendung des Leistungszählers erfordert möglicherweise die Freigabe des Zugriffs für Anwendungen ohne Sonderrechte.
• Geräte, die keine hochauflösenden Timer unterstützen, verwenden standardmäßig eine Granularität von einer Millisekunde.

Weitere Beispiele für Benchmarks finden Sie unter „Writing a Benchmark “ im Tutorial „ Qt Test “.

Verwendung globaler Testdaten

Sie können „ initTestCase_data() “ so definieren, dass eine globale Testdatentabelle eingerichtet wird. 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 also g Zeilen in der globalen Datentabelle und d Zeilen in der testeigenen Datentabelle vorhanden sind, beträgt die Anzahl der Ausführungen dieses Tests g mal d.

Globale Daten werden mithilfe des Makros „ QFETCH_GLOBAL()“ aus der Tabelle abgerufen.

Im Folgenden sind typische Anwendungsfälle für globale Testdaten aufgeführt:

• Auswahl unter den verfügbaren Datenbank-Backends in QSql-Tests, um jeden Test mit jeder Datenbank auszuführen.
• Durchführung aller Netzwerktests mit und ohne SSL (HTTP versus HTTPS) sowie mit und ohne Proxy.
• Testen eines Timers mit einer hochpräzisen Uhr und mit einer groben Uhr.
• Auswahl, ob ein Parser aus einer „ QByteArray “ oder aus einer „ QIODevice “ lesen soll.

Beispielsweise, 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 vorangestellten Testklassen-Namen) übergeben, um nur die Tests dieser einen Funktion auszuführen. Wenn die Testklasse globale Daten enthält oder die Funktion datengesteuert ist, können Sie nach einem Doppelpunkt ein Daten-Tag 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 diese mit einem Doppelpunkt dazwischen, wobei das globale Daten-Tag an erster Stelle steht. Zum Beispiel

./testqlocale roundTripInt:zero

wird der Testfall „ zero “ des obigen Tests „ roundTripInt() “ (vorausgesetzt, die Klasse „ TestQLocale “ wurde zu einer ausführbaren Datei „ testqlocale “ kompiliert) in jeder der durch „ initTestCase_data() “ angegebenen Sprachumgebungen ausgeführt, während

./testqlocale roundTripInt:C

alle drei Testfälle von roundTripInt() nur in der C-Locale ausführt und

./testqlocale roundTripInt:C:zero

führt nur den Testfall „ zero “ in der Locale „C“ aus.

Eine derart detaillierte Steuerung darüber, welche Tests ausgeführt werden sollen, kann die Fehlersuche erheblich erleichtern, da Sie nur den einen Testfall Schritt für Schritt durchgehen müssen, bei dem ein Fehler aufgetreten ist.