Testversion - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

Test – Unit-Tests durchführen

ZUSAMMENFASSUNG

Versuch [ Optionen ] [ Datei | Paket | Modulen | Testfall | Testmethode ] ... ...

Versuch --help | -h

BESCHREIBUNG

„trial“ lädt eine Reihe von Komponententests, die aus Modulen, Paketen und Dateien stammen, und führt diese aus
in der Befehlszeile aufgeführt.

Die Testversion verwendet entweder Dateinamen oder vollständig qualifizierte Python-Namen als Argumente. Daher
„trial myproject/foo.py“, „trial myproject.foo“ und „trial
„myproject.foo.SomeTestCase.test_method“ sind alles gültige Möglichkeiten, die Testversion aufzurufen. Mehrere solcher
Argumente werden ebenfalls akzeptiert und ihre Reihenfolge bestimmt die Reihenfolge, in der die Argumente ausgeführt werden
entsprechende Tests werden durchgeführt.

Nach dem Ausführen der angegebenen Testsuite druckt der Standardtestreporter eine Zusammenfassung des Tests
laufen. Dies besteht aus dem Wort „PASSED“ (wenn alle Tests wie erwartet verliefen) oder „FAILED“ (falls vorhanden).
Test verhielt sich unerwartet), gefolgt von einer Zählung der verschiedenen Arten von Testergebnissen
angetroffen. Zu den möglichen Arten von Testergebnissen gehören:

Erfolge
Tests, die alle ihre Behauptungen bestanden und ohne Fehler abgeschlossen wurden. Diese sind
in der normalen Testausgabe mit „PASSED“ gekennzeichnet.

Ausfälle
Tests, bei denen eine Behauptung fehlgeschlagen ist, werden als self.fail() bezeichnet oder explizit ausgelöst
self.failureException aus irgendeinem Grund. Diese werden im normalen Test mit „FEHLGESCHLAGEN“ gekennzeichnet
Ausgabe.

Fehler Tests, die eine unerwartete Ausnahme ausgelöst haben (einschließlich AssertionError), testet dies
führte dazu, dass die Methode „tearDown()“ eine Ausnahme auslöste, Tests, die länger als ausgeführt werden
das Timeout-Intervall, Tests, die dazu führten, dass etwas „twisted.python.log.err()“ aufrief
ohne anschließend self.flushLoggedErrors() aufzurufen, Tests, die den Reaktor verlassen
in einem unsauberen Zustand usw. Diese werden in der normalen Testausgabe mit „ERROR“ gekennzeichnet.

Beachten Sie, dass dies der Fall ist, da nach der Rückkehr der eigentlichen Testmethode Fehler verursacht werden können
Es ist möglich, dass ein einzelner Test sowohl als Fehler als auch als Fehlschlag gemeldet wird
Die Gesamtzahl der Testergebnisse kann größer sein als die Gesamtzahl der Tests
hingerichtet.

überspringt Tests, die übersprungen wurden, normalerweise aufgrund fehlender Abhängigkeiten. Diese sind gekennzeichnet
„SKIPPED“ in der normalen Testausgabe.

erwartete Fehler
Tests, die fehlgeschlagen sind, von denen aber erwartet wurde, dass sie fehlschlagen, normalerweise, weil der Test für einen ist
Funktion, die noch nicht implementiert wurde. Diese sind im Normalfall mit „TODO“ gekennzeichnet
Testausgabe.

unerwartete Erfolge
Tests, die mit Ausnahme einiger Tests unter „expectedFailures“ hätten aufgeführt werden sollen
Grund, warum der Test erfolgreich war. Diese sind mit „ERFOLGREICH!?!“ gekennzeichnet. in der normalen Testausgabe.

OPTIONAL

-j, --Arbeitsplätze Anzahl
Legen Sie die Anzahl der auszuführenden Prozessarbeiter fest. Es steht im Konflikt mit dem Debug, Exitfirst
und Profiloptionen.

-b, --debuggen
Führen Sie die Tests in einem Debugger aus. Wenn dieser Debugger „pdb“ ist (was die Standardeinstellung ist, wenn
nicht angegeben), wird eine „.pdbrc“-Datei aus dem aktuellen Verzeichnis geladen, sofern vorhanden.
Führt auch Post-Mortem-Debugging bei Ausnahmen durch.

-B, --debug-stacktraces
Melden Sie verzögerte Erstellung und Callback-Stack-Traces.

--Abdeckung
Generieren Sie Abdeckungsinformationen im Unterverzeichnis „coverage“ der Testversion
Verzeichnis (standardmäßig „_trial_temp“). Für jedes Python-Modul, das von berührt wird
Bei der Ausführung der angegebenen Tests wird eine Datei im Coverage-Verzeichnis erstellt
benannt nach dem vollqualifizierten Namen des Moduls mit dem Suffix „.cover“. Zum Beispiel,
Da der Trial-Test-Runner in Python geschrieben ist, wird das Coverage-Verzeichnis dies tun
enthalten fast immer eine Datei mit dem Namen „twisted.trial.runner.cover“.

Jede „.cover“-Datei enthält eine Kopie der Python-Quelle des betreffenden Moduls.
mit einem Präfix am Anfang jeder Zeile, die Informationen zur Abdeckung enthält. Für
Bei Zeilen, die nicht ausführbar sind (Leerzeilen, Kommentare usw.), ist das Präfix leer.
Für ausführbare Zeilen, die im Verlauf der Testsuite ausgeführt wurden, ist das Präfix a
Zahl, die angibt, wie oft diese Zeile ausgeführt wurde. Die Zeichenfolge „>>>>>>“
Stellt ausführbaren Zeilen ein Präfix voran, die im Verlauf der Testsuite nicht ausgeführt wurden.

Beachten Sie, dass diese Funktionalität die Funktion sys.settrace() von Python verwendet und diese daher testet
Der Aufruf von sys.settrace() selbst beeinträchtigt wahrscheinlich die Abdeckungsfunktionalität der Testversion.

- Debugger
Gibt den Debugger an, der verwendet werden soll, wenn die Option --debug übergeben wird. Das Argument
sollte der vollständig qualifizierte Name eines Objekts sein, das dieselbe Schnittstelle implementiert
als „pdb“ der Standardbibliothek.

--disablegc
Deaktivieren Sie den Garbage Collector für die Dauer des Testlaufs. Wie jeder Test ist
Durch Ausführen und Testen werden die TestResult-Objekte gespeichert, was bedeutet, dass Python Müll ist
Der Kollektor hat mehr Nicht-Müllobjekte zum Durchwühlen, sodass jeder Müll-
Die Sammlung läuft etwas langsamer. Das vollständige Deaktivieren der Garbage Collection führt zu Problemen
Einige Testsuiten werden schneller abgeschlossen (contrast --force-gc, unten), auf Kosten von
erhöht (möglicherweise stark) den Speicherverbrauch. Diese Option führt auch Tests durch
etwas deterministischer, was unter extremen Umständen beim Debuggen hilfreich sein könnte.

-e, --rterrors
Drucken Sie Tracebacks auf die Standardausgabe, sobald sie auftreten.

--force-gc
Führen Sie gc.collect() vor und nach jedem Testfall aus. Dies kann zur Isolierung genutzt werden
Fehler, die beim Sammeln von Objekten auftreten. Diese Option wäre die Standardeinstellung.
außer, dass Tests dadurch etwa zehnmal langsamer ausgeführt werden.

-h, --help
Drucken Sie eine Nutzungsmeldung in die Standardausgabe und beenden Sie den Vorgang.

--help-order
Drucken Sie dann eine Liste möglicher Reihenfolgen aus, in denen TestCase-Testmethoden ausgeführt werden können
Ausfahrt. Die Bestellungen können mit der unten beschriebenen Option --order verwendet werden.

--help-reporters
Drucken Sie eine Liste gültiger Reporter in die Standardausgabe und beenden Sie den Vorgang. Reporter können sein
wird mit der unten beschriebenen Option --reporter ausgewählt.

--help-reaktoren
Drucken Sie eine Liste möglicher Reaktoren in die Standardausgabe und beenden Sie den Vorgang. Nicht alle aufgeführt
Reaktoren sind auf jeder Plattform verfügbar. Mit dem können Reaktoren ausgewählt werden
--reactor-Option, die unten beschrieben wird.

-l, --Logdatei Logdatei
Leiten Sie das Protokoll in eine andere Datei um. Die Standarddatei ist „test.log“. Logdatei is
relativ zu _trial_temp.

-n, --Probelauf
Gehen Sie alle Tests durch und lassen Sie sie bestehen, ohne zu laufen.

-N, --no-recurse
Standardmäßig durchläuft die Testversion die Pakete, um jedes Modul in jedem zu finden
Unterpaket. Es sei denn, Sie geben diese Option an.

--nopm Springen Sie nicht automatisch in den Debugger, um Ausnahmen nachträglich zu analysieren.
Nur in Verbindung mit --debug verwendbar.

--Auftrag Auftrag
Geben Sie an, in welcher Reihenfolge die einzelnen Testmethoden innerhalb der angegebenen Testfälle ausgeführt werden sollen.
Standardmäßig werden sie alphabetisch ausgeführt. Eine Liste anderer gültiger Befehle finden Sie unter --help-order
Werte.

--Profil
Führen Sie Tests unter dem Python-Profiler aus.

-r, --Reaktor Reaktor
Wählen Sie den zu verwendenden Reaktor. Eine Liste finden Sie unter --help-reactors.

--recursionlimit begrenzen
Legen Sie das Rekursionslimit von Python fest. Siehe sys.setrecursionlimit().

--Reporter Reporter
Wählen Sie den Reporter aus, der für die Testausgabe verwendet werden soll. Verwenden Sie dazu die Option --help-reporters
Sehen Sie sich eine Liste gültiger Reporter an.

-x, --Zuerst verlassen
Stoppen Sie den Testlauf nach dem ersten Test, der nicht erfolgreich war. Das beinhaltet
Misserfolge, Fehler oder unerwartete Erfolge. Funktioniert nicht mit der Option --jobs
zur Zeit.

--speien Drucken Sie ein wahnsinnig ausführliches Protokoll über alles, was passiert. Nützlich beim Debuggen
friert komplexen Code ein oder sperrt ihn.

--tbformat Format
Format zum Anzeigen von Tracebacks. Akzeptable Werte sind „default“, „brief“ und
„ausführlich“. „brief“ erzeugt Tracebacks, die gut mit Emacs' GUD harmonieren.

--temp-Verzeichnis Verzeichnis
WARNUNG: Verwenden Sie diese Option nur, wenn Sie wissen, was Sie tun. Standardmäßig,
„trial“ erstellt ein Verzeichnis mit dem Namen „_trial_temp“ unter dem aktuellen Arbeitsverzeichnis.
Beim Probelauf geht es zuerst Löschungen dieses Verzeichnis, erstellt es dann und ändert es dann
in das Verzeichnis, um die Tests auszuführen. Die Protokolldatei und eventuelle Abdeckungsdateien werden gespeichert
Hier. Verwenden Sie diese Option, wenn Sie den Testlauf in einem anderen Verzeichnis als durchführen möchten
_trial_temp. Seien Sie gewarnt, der Prozess wird stattfinden löschen das Verzeichnis, bevor Sie es neu erstellen.

--testmodule Dateinamen
Bitten Sie um eine Probeprüfung Dateinamen und führen Sie alle im Emacs-Stil angegebenen Tests aus
Puffervariable „Testfallname“.

--unclean-warnings
Ab Twisted 8.0 meldet die Testversion einen Fehler, wenn der Reaktor nicht sauber bleibt
Ende des Tests. Diese Option wird bereitgestellt, um die Migration von Twisted 2.5 auf zu unterstützen
Twisted 8.0 und höher. Wenn Sie diese Option aktivieren, werden die Fehler in Warnungen umgewandelt.

-u, --bis-zum Scheitern
Führen Sie die Tests so lange durch, bis einer von ihnen einen Fehler oder einen Fehler auslöst. Das ist
Besonders nützlich für die Reproduktion intermittierender Fehler.

--Version
Gibt die Versionsnummer von Twisted aus und beendet den Vorgang.

--without-module Modulnamen
Simulieren Sie das Fehlen der angegebenen durch Kommas getrennten Liste von Modulen. Das macht es
Es sieht so aus, als wären die Module nicht im System vorhanden, was dazu führt, dass Tests dies überprüfen
Verhalten für diese Konfiguration.

-z, --willkürlich Samen
Führen Sie die Tests in zufälliger Reihenfolge mit dem angegebenen Startwert aus. Übergeben Sie diese Option nicht, wenn
Sie übergeben auch --order.

Nutzen Sie die Testversion online über die Dienste von onworks.net