EnglischFranzösischSpanisch

Ad


OnWorks-Favicon

lit-3.7 - Online in der Cloud

Führen Sie lit-3.7 im kostenlosen OnWorks-Hosting-Provider über Ubuntu Online, Fedora Online, Windows-Online-Emulator oder MAC OS-Online-Emulator aus

Dies ist der Befehl lit-3.7, der im kostenlosen OnWorks-Hosting-Provider mit einer unserer zahlreichen kostenlosen Online-Workstations wie Ubuntu Online, Fedora Online, Windows-Online-Emulator oder MAC OS-Online-Emulator ausgeführt werden kann

PROGRAMM:

NAME/FUNKTION


leuchtet - Integrierter LLVM-Tester

ZUSAMMENFASSUNG


lit [Optionen] [Tests]

BESCHREIBUNG


lit ist ein portables Tool zum Ausführen von LLVM- und Clang-Testsuiten, das ihre
Ergebnisse und gibt Hinweise auf Fehler. lit ist als Leichtgewicht konzipiert
Testtool mit möglichst einfacher Benutzeroberfläche.

lit sollte mit einem oder mehreren ausgeführt werden Tests in der Befehlszeile angegeben auszuführen. Tests können
entweder einzelne Testdateien oder Verzeichnisse sein, um nach Tests zu suchen (siehe TESTEN DISCOVERY).

Jeder angegebene Test wird ausgeführt (möglicherweise parallel) und sobald alle Tests abgeschlossen sind
gelaufen lit druckt zusammenfassende Informationen über die Anzahl der bestandenen oder nicht bestandenen Tests
(sehen TESTEN STATUS ERGEBNISSE). Die lit Programm wird mit einem Nicht-Null-Exit-Code ausgeführt, falls vorhanden
Tests scheitern.

Standardmäßig lit verwendet eine prägnante Fortschrittsanzeige und druckt nur eine Zusammenfassung
Informationen zu Testfehlern. Sehen AUSGABE OPTIONAL für Optionen zur Steuerung der lit
Fortschrittsanzeige und Ausgabe.

lit enthält auch eine Reihe von Optionen zur Steuerung der Testausführung (spezifische
Funktionen können vom jeweiligen Testformat abhängen). Sehen EXECUTION OPTIONAL Für weitere
Informationen.

Schließlich lit unterstützt auch zusätzliche Optionen, um nur eine Teilmenge der Optionen auszuführen
in der Befehlszeile angegeben, siehe SELECTION OPTIONAL um mehr zu erfahren.

Benutzer, die sich für die . interessieren lit Architektur oder Design a lit Testimplementierung sollte
sehen LIT INFRASTRUKTUR.

ALLGEMEIN OPTIONAL


-H, --help
Zeige den lit Hilfe-Nachricht.

-j N, --threads=N
Führen Sie N parallel testen. Standardmäßig wird dies automatisch so ausgewählt, dass es mit dem übereinstimmt
Anzahl der erkannten verfügbaren CPUs.

--config-prefix=NAME
Suchen Sie nach HEIF-Bilderweiterungen. NAME/FUNKTION.cfg und NAME/FUNKTION.site.cfg wann Suche für Test Suiten, beantragen müssen of
lit.cfg und lit.site.cfg.

-D NAME, -D NAME=WERT, --param NAME, --param NAME = WERT
Einen benutzerdefinierten Parameter hinzufügen NAME/FUNKTION mit dem gegebenen BEWERTUNG (oder die leere Zeichenfolge, wenn nicht
gegeben). Die Bedeutung und Verwendung dieser Parameter hängt von der Testsuite ab.

AUSGABE OPTIONAL


-Q, --ruhig
Unterdrücken Sie alle Ausgaben außer bei Testfehlern.

-S, --prägnant
Weniger Ausgaben anzeigen, zum Beispiel keine Informationen zu bestandenen Tests anzeigen.

-in, - ausführlich
Zeigen Sie mehr Informationen zu Testfehlern an, z. B. stattdessen die gesamte Testausgabe
nur das Testergebnis.

--no-progress-bar
Verwenden Sie keine auf Flüchen basierende Fortschrittsanzeige.

--show-nicht unterstützt
Zeigt die Namen nicht unterstützter Tests an.

--show-xfail
Zeigen Sie die Namen der Tests an, von denen erwartet wurde, dass sie fehlschlagen.

EXECUTION OPTIONAL


--path=PFAD
Geben Sie eine zusätzliche an PATH bei der Suche nach ausführbaren Dateien in Tests zu verwenden.

--vg Führen Sie einzelne Tests unter valgrind aus (mit dem memcheck-Tool). Die
--error-exitcode Argument für Valgrind wird verwendet, damit Valgrind-Ausfälle verursachen
das Programm mit einem Nicht-Null-Status zu beenden.

Wenn diese Option aktiviert ist, lit wird auch automatisch ein "Valgrind"
Funktion, die verwendet werden kann, um bestimmte bedingt zu deaktivieren (oder einen Fehler zu erwarten)
Tests.

--vg-arg=ARG
Wann --vg verwendet wird, geben Sie ein zusätzliches Argument für die Übergabe an Valgrind sich.

--vg-leck
Wann --vg verwendet wird, aktivieren Sie Speicherleckprüfungen. Wenn diese Option aktiviert ist, lit
wird auch automatisch ein "vg_leck"Funktion, die verwendet werden kann, um
bestimmte Tests bedingt deaktivieren (oder einen Fehler erwarten).

--Zeittests
Verfolgen Sie die Wandzeit, die einzelne Tests zur Ausführung benötigen, und fügen Sie die Ergebnisse in
die zusammenfassende Ausgabe. Dies ist nützlich, um zu bestimmen, welche Tests in einer Testsuite
nehmen sich die meiste Zeit für die Ausführung. Beachten Sie, dass diese Option am nützlichsten ist mit -j 1.

SELECTION OPTIONAL


--max-tests=N
Höchstens laufen N testen und dann beenden.

--max-time=N
Höchstens ausgeben N Sekunden (ungefähr) laufende Tests und dann beenden.

--Mischen
Führen Sie die Tests in zufälliger Reihenfolge durch.

ZUSÄTZLICH OPTIONAL


--debuggen
Führen Sie lit im Debug-Modus zum Debuggen von Konfigurationsproblemen und lit sich.

--Show-Suiten
Listen Sie die erkannten Testsuiten auf und beenden Sie den Vorgang.

--show-tests
Alle erkannten Tests auflisten und beenden.

EXIT STATUS


lit wird mit einem Exit-Code von 1 beendet, wenn FAIL- oder XPASS-Ergebnisse vorliegen. Andernfalls,
es wird mit dem Status 0 beendet. Andere Exit-Codes werden für nicht testbezogene Fehler verwendet
(zB ein Benutzerfehler oder ein interner Programmfehler).

TESTEN DISCOVERY


Die an . übergebenen Eingaben lit können entweder einzelne Tests oder ganze Verzeichnisse sein oder
Hierarchien der auszuführenden Tests. Wann lit startet, als erstes konvertiert es die
Eingaben in eine vollständige Liste von Tests, die als Teil ausgeführt werden sollen Test Entdeckung.

Im lit Modell, jeder Test muss in einigen vorhanden sein Test Suite. lit löst die Eingaben auf
auf der Befehlszeile angegeben, um Suiten zu testen, indem Sie vom Eingabepfad nach oben suchen
bis es ein findet lit.cfg or lit.site.cfg Datei. Diese Dateien dienen sowohl als Markierung für den Test
Suiten und als Konfigurationsdateien, die lit lädt, um zu verstehen, wie man findet und
Führen Sie die Tests innerhalb der Testsuite aus.

Sobald lit hat die Eingaben in Testsuiten abgebildet, sie durchläuft die Liste der Eingaben und fügt hinzu
Tests für einzelne Dateien und rekursives Suchen nach Tests in Verzeichnissen.

Dieses Verhalten macht es einfach, eine Teilmenge der auszuführenden Tests anzugeben, während gleichzeitig die
Testsuite-Konfiguration, um genau zu steuern, wie Tests interpretiert werden. Zusätzlich, lit
identifiziert Tests immer nach der Testsuite, in der sie sich befinden, und ihrem relativen Pfad innerhalb der
Testsuite. Bei entsprechend konfigurierten Projekten ermöglicht dies lit bequem zu bieten
und flexible Unterstützung für Out-of-Tree-Builds.

TESTEN STATUS ERGEBNISSE


Jeder Test führt letztendlich zu einem der folgenden sechs Ergebnisse:

PASS
Der Test war erfolgreich.

XFAIL
Der Test ist fehlgeschlagen, aber das wird erwartet. Dies wird für Testformate verwendet, die
angeben, dass ein Test derzeit nicht funktioniert, ihn aber in der Testsuite belassen möchten.

XPASS
Der Test war erfolgreich, aber es wurde erwartet, dass er fehlschlägt. Dies wird für Tests verwendet, die
angegeben, dass sie voraussichtlich fehlschlagen werden, aber jetzt erfolgreich sind (im Allgemeinen, weil die Funktion
der Test war defekt und wurde behoben).

FAIL
Der Test ist fehlgeschlagen.

UNGELÖST
Das Testergebnis konnte nicht ermittelt werden. Dies tritt beispielsweise auf, wenn der Test
nicht ausgeführt werden, der Test selbst ist ungültig oder der Test wurde unterbrochen.

NICHT UNTERSTÜTZT
Der Test wird in dieser Umgebung nicht unterstützt. Dies wird von Testformaten verwendet, die
nicht unterstützte Tests melden.

Abhängig vom Testformat können Tests zusätzliche Informationen über ihren Status liefern
(in der Regel nur bei Fehlern). Siehe die AUSGABE OPTIONAL Abschnitt für weitere Informationen.

LIT INFRASTRUKTUR


Dieser Abschnitt beschreibt die lit Testarchitektur für Benutzer, die daran interessiert sind, eine neue
lit Testimplementierung oder Erweiterung einer bestehenden.

lit richtig ist in erster Linie eine Infrastruktur zum Auffinden und Ausführen beliebiger Tests, und
um eine einzige praktische Schnittstelle für diese Tests bereitzustellen. lit selbst kann nicht laufen
Tests, vielmehr wird diese Logik definiert durch Test Suiten.

TESTEN SUITES
Wie in der TESTEN DISCOVERY, Tests befinden sich immer innerhalb von a Test Suite. Testsuiten
dienen dazu, das Format der darin enthaltenen Tests, die Logik zum Auffinden dieser Tests,
und alle zusätzlichen Informationen zum Ausführen der Tests.

lit identifiziert Testsuiten als Verzeichnisse, die lit.cfg or lit.site.cfg Dateien (siehe
ebenfalls --config-Präfix). Testsuiten werden zunächst durch rekursives Suchen entdeckt
die Verzeichnishierarchie für alle Eingabedateien, die auf der Befehlszeile übergeben werden. Sie können verwenden
--Show-Suiten um die erkannten Testsuiten beim Start anzuzeigen.

Sobald eine Testsuite erkannt wurde, wird ihre Konfigurationsdatei geladen. Konfigurationsdateien selbst sind
Python-Module, die ausgeführt werden. Wenn die Konfigurationsdatei ausgeführt wird, sind zwei wichtige
globale Variablen sind vordefiniert:

lit_config
Die Welt lit Konfigurationsobjekt (a LitConfig -Instanz), die den eingebauten
Testformate, globale Konfigurationsparameter und andere Hilfsroutinen für
Testkonfigurationen implementieren.

Config
Dies ist das Konfigurationsobjekt (a Testkonfiguration -Instanz) für die Testsuite, die die
config-Datei wird erwartet, dass sie gefüllt wird. Die folgenden Variablen sind auch auf dem . verfügbar
Config -Objekt, von denen einige durch die Konfiguration gesetzt werden müssen und andere optional sind oder
vordefiniert:

Name [erforderlich] Der Name der Testsuite zur Verwendung in Berichten und Diagnosen.

test_format [erforderlich] Das Testformatobjekt, das zum Erkennen und Ausführen verwendet wird
Tests in der Testsuite. Im Allgemeinen wird dies ein integriertes Testformat sein, das von verfügbar ist
Leuchtformate Modul.

test_source_root Der Dateisystempfad zum Stammverzeichnis der Testsuite. Für Out-of-dir-Builds
Dies ist das Verzeichnis, das nach Tests durchsucht wird.

test_exec_root Bei Builds außerhalb des Verzeichnisses der Pfad zum Stamm der Testsuite im Objekt
Verzeichnis. Hier werden Tests ausgeführt und temporäre Ausgabedateien platziert.

Umwelt Ein Wörterbuch, das die Umgebung darstellt, die beim Ausführen von Tests in
die Suite.

Suffixe Aussichten für lit Testformate, die Verzeichnisse nach Tests durchsuchen, diese Variable ist eine Liste
von Suffixen, um Testdateien zu identifizieren. Benutzt von: ShTest.

Substitutionen Aussichten für lit Testformate, die Variablen in einem Testskript ersetzen, die
Liste der durchzuführenden Auswechslungen. Benutzt von: ShTest.

nicht unterstützt Markieren Sie ein nicht unterstütztes Verzeichnis, alle Tests darin werden gemeldet als
nicht unterstützt. Benutzt von: ShTest.

Elternteil Die übergeordnete Konfiguration, dies ist das Konfigurationsobjekt für das Verzeichnis, das . enthält
die Testsuite oder Keine.

Wurzel Die Root-Konfiguration. Dies ist die oberste lit Konfiguration im Projekt.

Rohrfehler Normalerweise schlägt ein Test mit einer Shell-Pipe fehl, wenn einer der Befehle auf der Pipe
Scheitern. Wenn dies nicht erwünscht ist, führt das Setzen dieser Variable auf false dazu, dass der Test nur fehlschlägt
wenn der letzte Befehl in der Pipe fehlschlägt.

TESTEN DISCOVERY
Sobald Testsuiten gefunden wurden, lit durchläuft rekursiv das Quellverzeichnis (folgend
test_source_root) auf der Suche nach Tests. Wann lit ein Unterverzeichnis betritt, prüft es zuerst auf
Überprüfen Sie, ob in diesem Verzeichnis eine verschachtelte Testsuite definiert ist. Wenn ja, wird diese Testsuite geladen
rekursiv, ansonsten instanziiert es eine lokale Testkonfiguration für das Verzeichnis (siehe LOCAL
CONFIGURATION DATEIEN).

Tests werden durch die Testsuite identifiziert, in der sie enthalten sind, und den relativen Pfad
in dieser Suite. Beachten Sie, dass der relative Pfad möglicherweise nicht auf eine tatsächliche Datei auf der Festplatte verweist.
einige Testformate (wie GoogleTest) "virtuelle Tests" definieren, die einen Pfad haben, der
enthält sowohl den Pfad zur eigentlichen Testdatei als auch einen Unterpfad zur Identifizierung des virtuellen Tests.

LOCAL CONFIGURATION DATEIEN
Wann lit lädt ein Unterverzeichnis in einer Testsuite, es instanziiert eine lokale Testkonfiguration
durch Klonen der Konfiguration für das übergeordnete Verzeichnis --- das Stammverzeichnis dieser Konfiguration
Chain wird immer eine Testsuite sein. Sobald die Testkonfiguration geklont ist lit prüft auf a
lit.local.cfg Datei im Unterverzeichnis. Falls vorhanden, wird diese Datei geladen und kann
verwendet, um die Konfiguration für jedes einzelne Verzeichnis zu spezialisieren. Diese Einrichtung kann
Wird verwendet, um Unterverzeichnisse optionaler Tests zu definieren oder andere Konfigurationen zu ändern
Parameter --- zum Beispiel zum Ändern des Testformats oder der Suffixe, die den Test identifizieren
Dateien.

TESTEN RENNE AUSGABE FORMAT
Das lit Ausgabe für einen Testlauf entspricht dem folgenden Schema, kurz und ausführlich
(obwohl im kurzen Modus keine PASS-Linien angezeigt werden). Dieses Schema wurde gewählt
relativ einfach von einer Maschine zuverlässig zu parsen (zum Beispiel in buildbot log
Scraping) und für andere Tools zum Generieren.

Es wird erwartet, dass jedes Testergebnis in einer Zeile erscheint, die mit Folgendem übereinstimmt:

: ( )

woher ist ein Standardtestergebnis wie PASS, FAIL, XFAIL, XPASS,
UNGELÖST oder NICHT UNTERSTÜTZT. Die Leistungsergebniscodes von IMPROVED und REGRESSED sind
auch erlaubt.

Das <test Name> Feld kann aus einer beliebigen Zeichenfolge bestehen, die keinen Zeilenumbruch enthält.

Das <Fortschritt info> Feld kann verwendet werden, um Fortschrittsinformationen wie (1/300) oder . zu melden
kann leer sein, aber auch wenn leer, sind die Klammern erforderlich.

Jedes Testergebnis kann im Folgenden zusätzliche (mehrzeilige) Protokollinformationen enthalten
Format:

PRÜFUNG '( )'
... Log-Meldung ...


woher <test Name> sollte der Name eines vorangegangenen gemeldeten Tests sein, <log Leitlinie> ist eine
Zeichenfolge von "*"-Zeichen at am wenigsten vier Zeichen lang (die empfohlene Länge beträgt 20) und
<nachfolgend Leitlinie> ist eine beliebige (ungeparste) Zeichenfolge.

Das Folgende ist ein Beispiel für eine Testlaufausgabe, die aus vier Tests A, B, C und . besteht
D und eine Protokollnachricht für den fehlgeschlagenen Test C:

PASS: A (1 von 4)
PASS: B (2 von 4)
FEHLER: C (3 von 4)
******************** TEST 'C' FEHLGESCHLAGEN ********************
Test 'C' ist aufgrund von Exitcode 1 fehlgeschlagen.
********************
PASS: D (4 von 4)

LIT BEISPIEL TESTS
Das lit Distribution enthält mehrere Beispielimplementierungen von Testsuiten in der
BeispielTests Verzeichnis.

Verwenden Sie lit-3.7 online mit den onworks.net-Diensten


Kostenlose Server & Workstations

Laden Sie Windows- und Linux-Apps herunter

Linux-Befehle

Ad