BazelCon 2022 findet vom 16. bis 17. November in New York und online statt.
Jetzt anmelden

Enzyklopädie testen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Eine umfassende Spezifikation der Testausführungsumgebung.

Hintergrund

Die Istio BUILD-Sprache enthält Regeln, mit denen automatisierte Programmierprogramme in vielen Sprachen definiert werden können.

Tests werden mit bazel test ausgeführt.

Nutzer können Binärprogramme auch direkt ausführen. Das ist zulässig, wird aber nicht empfohlen, da ein solcher Aufruf nicht den unten beschriebenen Einzugsermächtigungen entspricht.

Tests sollten hermetisch sein, d. h. auf nur Ressourcen zugreifen, für die eine angegebene Abhängigkeit gilt. Wenn Tests nicht ordnungsgemäß herzhaft sind, liefern sie keine reproduzierbaren Ergebnisse. Dies kann ein erhebliches Problem für die Fehlersuche (Ermittlung der Änderungen, Testfehler), die Release-Prüfung sowie die Ressourcenisolierung von Tests sein (automatische Test-Frameworks erfordern keinen DDOS für einen Server, da einige Tests damit kommunizieren).

Ziel

Auf dieser Seite geht es darum, die Laufzeitumgebung für das erwartete Verhalten von Istio-Tests offiziell aufzubauen. Außerdem gelten dann Anforderungen für den Test-Ausführer und das Build-System.

Die Testumgebungsspezifikation hilft Testautoren, sich auf nicht angegebenes Verhalten zu verlassen und gibt der Testinfrastruktur mehr Freiheit, Änderungen an der Implementierung vorzunehmen. Durch die Spezifikation werden einige Lücken verschärft, die derzeit viele Tests bestehen, auch wenn sie nicht richtig hermetisch, deterministisch und konsistent sind.

Diese Seite ist sowohl normativ als auch maßgeblich. Wenn diese Spezifikation und das implementierte Verhalten des Test-Ausführers nicht übereinstimmen, hat die Spezifikation Vorrang.

Vorgeschlagene Spezifikation

Die Schlüsselwörter MÜSSEN;MÜSSEN;UND

Zweck der Tests

Mit Istio-Tests können Sie ein bestimmtes Attribut der Quelldateien im Repository prüfen. Auf dieser Seite enthalten Quelldateien u. a. Testdaten, Goldausgaben und alles andere, das der Versionsverwaltung unterliegt. Ein Nutzer schreibt einen Test, um eine Variante zu bestätigen, die erhalten bleiben soll. Andere Nutzer führen den Test später aus, um zu prüfen, ob die Variante fehlerhaft ist. Wenn der Test von anderen Variablen als Quelldateien abhängig ist (nicht hermetisch), wird sein Wert verringert, weil die späteren Nutzer nicht sicher sein können, ob die Änderungen fehlgeschlagen sind, wenn der Test beendet wird.

Das Ergebnis eines Tests darf daher nur von folgenden Faktoren abhängen:

  • Quelldateien, von denen der Test eine Abhängigkeit aufweist
  • Produkte des Build-Systems, von dem der Test eine deklarierte Abhängigkeit hat
  • Ressourcen, deren Verhalten vom Test-Ausführer garantiert wird,

Dieses Verhalten wird derzeit nicht erzwungen. Testläufer behalten sich jedoch das Recht vor, eine solche Erzwingung in Zukunft hinzuzufügen.

Rolle des Build-Systems

Testregeln ähneln analogen binären Regeln, da jede Regel ein ausführbares Programm enthalten muss. Für einige Sprachen ist dies ein Stub-Programm, das ein sprachspezifisches Riemen mit dem Testcode kombiniert. Testregeln müssen auch andere Ausgaben liefern. Zusätzlich zur primären ausführbaren Testdatei benötigt der Test-Ausführer ein Manifest mit Runfiles, Eingabedateien, die während der Laufzeit für den Test zur Verfügung gestellt werden, und benötigt möglicherweise Informationen zu Typ, Größe und Tags eines Tests.

Das Build-System kann die Runfiles verwenden, um Code und Daten bereitzustellen. Dies kann zur Optimierung verwendet werden, um jedes TestBinärprogramm kleiner zu machen, indem Dateien für verschiedene Tests freigegeben werden, z. B. durch Verwendung der dynamischen Verknüpfung. Das Build-System sollte dafür sorgen, dass die generierte ausführbare Datei diese Dateien über das Ausführungs-Image lädt, das vom Test-Ausführer bereitgestellt wird, und nicht auf absolute Speicherorte in der Quell- oder Ausgabestruktur.

Rolle des Test-Ausführers

Aus Sicht des Test-Ausführers ist jeder Test ein Programm, das mit execve() aufgerufen werden kann. Es gibt möglicherweise andere Möglichkeiten, Tests durchzuführen. Eine IDE kann beispielsweise die Ausführung von Java-Tests während des Vorgangs ermöglichen. Das Ergebnis des Tests als eigenständiger Prozess muss jedoch als verlässlicher Prozess betrachtet werden. Wenn ein Testvorgang vollständig abgeschlossen wird und normal mit dem Exitcode 0 beendet wird, ist der Test bestanden. Alle anderen Ergebnisse gelten als Testfehler. Insbesondere das Schreiben eines der Strings PASS oder FAIL in ststout hat keine Bedeutung für den Test-Ausführer.

Wenn die Ausführung eines Tests zu lange dauert, ein Ressourcenlimit überschritten wird oder der Test-Ausführer ein unzulässiges Verhalten erkennt, kann er abgebrochen werden. Der Läufer darf die Prüfung nicht als bestanden melden, nachdem ein Signal an den Testprozess bzw. dessen untergeordnete Geräte gesendet wurde.

Das gesamte Testziel (nicht einzelne Methoden oder Tests) erhält eine begrenzte Zeit, bis es abgeschlossen ist. Das Zeitlimit für einen Test basiert auf seinem Attribut timeout und zwar gemäß der folgenden Tabelle:

timeout Zeitlimit (Sek.)
short 60
mittel 300
long 900
ewig 3.600

Tests, für die kein Zeitlimit explizit festgelegt ist, enthalten ein impliziertes Ergebnis, das auf dem Test size basiert:

Größe Impliziertes Zeitlimit-Label
S short
medium mittel
L long
enorm ewig

Für einen "großen Test ohne explizite Zeitüberschreitung" werden 900 Sekunden für die Ausführung zugewiesen. Für den Test „Mittel“ mit einer Zeitüberschreitung von „Kurz“ werden 60 Sekunden verwendet.

Anders als timeout bestimmt size zusätzlich auch die angenommene Spitzennutzung anderer Ressourcen (z. B. RAM), wenn der Test lokal ausgeführt wird, wie unter Allgemeine Definitionen beschrieben.

Alle Kombinationen aus size und timeout sind rechtsgültig. Deshalb kann eine „große alle“ als Zeitüberschreitung bei „kurz“ angegeben werden. Vermutlich würde man sehr furchtbar damit umgehen.

Tests können unabhängig von der Zeitüberschreitung beliebig schnell zurückgegeben werden. Bei einem übermäßigen Zeitlimit wird ein Test nicht mit einer Strafe belegt. Es kann jedoch sein, dass die Warnung so erscheint, dass sie möglichst nicht unzuverlässig wird.

Das Testzeitlimit kann mit dem Baye-Flag --test_timeout überschrieben werden, wenn es unter Bedingungen ausgeführt wird, die bekanntermaßen langsam sind. Die --test_timeout-Werte werden in Sekunden angegeben. --test_timeout=120 legt beispielsweise das Zeitlimit für den Test auf zwei Minuten fest.

Für Testzeitüberschreitungen wird außerdem eine empfohlene Untergrenze empfohlen:

timeout Mindestdauer (Sek.)
short 0
mittel 30
long 300
ewig 900

Wenn ein Test mit höherer Geschwindigkeit beispielsweise in 5, 5 Sekunden abgeschlossen ist, sollten Sie timeout = "short" oder size = "small" festlegen. Wenn Sie die Befehlszeile --test_verbose_timeout_warnings verwenden, werden die Tests angezeigt, deren angegebene Größe zu groß ist.

Testgrößen und Zeitüberschreitungen werden in der BUILD-Datei gemäß der Spezifikation angegeben. Wenn du keine Angabe machst, wird die Größe eines Tests standardmäßig auf „medium&medium“ gesetzt.

Wenn der Hauptprozess eines Tests beendet wird, aber einige seiner untergeordneten Elemente noch aktiv sind, sollte der Test-Ausführer den Ausführungsvorgang als erfolgreich oder fehlgeschlagen ansehen. Der Test-Ausführer kann alle Streuprozesse beenden. Bei den Tests dürfen auf diese Weise keine Datenlecks auftreten.

Fragmentierung testen

Tests können über Testfragmentierung parallelisiert werden. Wie Sie die Fragmentierung aktivieren, erfahren Sie unter --test_sharding_strategy und shard_count. Wenn die Fragmentierung aktiviert ist, wird der Test-Ausführer einmal pro Shard gestartet. Die Umgebungsvariable TEST_TOTAL_SHARDS ist die Anzahl der Shards und TEST_SHARD_INDEX ist der Shard-Index, der bei 0 beginnt. Runner verwenden diese Informationen, um auszuwählen, welche Tests ausgeführt werden sollen, z. B. mithilfe einer Round-Robin-Strategie. Nicht alle Test-Ausführer unterstützen Fragmentierung. Wenn ein Läufer Fragmentierung unterstützt, muss er das durch TEST_SHARD_STATUS_FILE zuletzt geänderte Datum der Datei erstellen oder aktualisieren. Andernfalls geht {5/} davon aus, dass er keine Fragmentierung unterstützt, und startet keine weiteren Läufer.

Ausgangsbedingungen

Beim Ausführen eines Tests muss der Test-Ausführer bestimmte Anfangsbedingungen festlegen.

Der Test-Ausführer muss jeden Test mit dem Pfad zur ausführbaren Testdatei in argv[0] aufrufen. Dieser Pfad muss relativ sein und sich unter dem aktuellen Verzeichnis „test“ befinden (siehe Runfiles-Baum). Der Test-Ausführer darf nur dann andere Argumente an einen Test übergeben, wenn der Nutzer dies explizit anfordert.

Der erste Block für die Umgebung sieht so aus:

Variable Wert Status
HOME Wert von $TEST_TMPDIR empfohlen
LANG unset required
LANGUAGE unset required
LC_ALL unset required
LC_COLLATE unset required
LC_CTYPE unset required
LC_MESSAGES unset required
LC_MONETARY unset required
LC_NUMERIC unset required
LC_TIME unset required
LD_LIBRARY_PATH durch Doppelpunkt getrennte Liste von Verzeichnissen, die gemeinsam genutzte Bibliotheken enthalten optional
JAVA_RUNFILES Wert von $TEST_SRCDIR Verworfen
LOGNAME Wert von $USER required
PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. empfohlen
PWD $TEST_SRCDIR/workspace-name empfohlen
SHLVL 2 empfohlen
TEST_INFRASTRUCTURE_FAILURE_FILE absoluter Pfad zu einer privaten Datei in einem beschreibbaren Verzeichnis. Diese Datei sollte nur dazu verwendet werden, Fehler zu melden, die von der Testinfrastruktur stammen, und nicht als allgemeiner Mechanismus zum Melden unzuverlässiger Fehler bei Tests. In diesem Zusammenhang ist die Testinfrastruktur als Systeme oder Bibliotheken definiert, die nicht testspezifisch sind, aber Fehler verursachen können. Die erste Zeile enthält den Namen der Testinfrastrukturkomponente, die den Fehler verursacht hat. Die zweite Zeile ist eine für Menschen lesbare Beschreibung des Fehlers. Zusätzliche Zeilen werden ignoriert. optional
TEST_LOGSPLITTER_OUTPUT_FILE absoluter Pfad zu einer privaten Datei in einem beschreibbaren Verzeichnis (wird zum Schreiben eines Logsplitter-Protokollzwischenspeichers verwendet) optional
TEST_PREMATURE_EXIT_FILE absoluter Pfad zu einer privaten Datei in einem beschreibbaren Verzeichnis (wird zum Erfassen von Aufrufen von exit() verwendet) optional
TEST_RANDOM_SEED Wenn die Option --runs_per_test verwendet wird, wird TEST_RANDOM_SEED für jeden einzelnen Testlauf auf run number gesetzt (beginnend mit 1). optional
TEST_RUN_NUMBER Wenn die Option --runs_per_test verwendet wird, wird TEST_RUN_NUMBER für jeden einzelnen Testlauf auf run number gesetzt (beginnend mit 1). optional
TEST_TARGET Der Name des getesteten Ziels optional
TEST_SIZE Der Test size optional
TEST_TIMEOUT Der Test timeout in Sekunden optional
TEST_SHARD_INDEX Shard-Index, wenn sharding verwendet wird optional
TEST_SHARD_STATUS_FILE Pfad zu Datei, die aufgerufen werden soll, um darauf hinzuweisen, dass sharding unterstützt wird optional
TEST_SRCDIR absoluter Pfad zur Basis des Runfiles-Baums required
TEST_TOTAL_SHARDS gesamt shard count, wenn sharding verwendet wird optional
TEST_TMPDIR absoluter Pfad zu einem privaten beschreibbaren Verzeichnis required
TEST_WORKSPACE Der Name des lokalen Repositorys optional
TEST_UNDECLARED_OUTPUTS_DIR absoluter Pfad zu einem privaten, beschreibbaren Verzeichnis (wird zum Schreiben nicht deklarierter Testausgaben verwendet) optional
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR absoluter Pfad zu einem privaten beschreibbaren Verzeichnis (wird zum Schreiben nicht deklarierter Testausgabeanmerkungen .part und .pb-Dateien verwendet). optional
TEST_WARNINGS_OUTPUT_FILE absoluter Pfad zu einer privaten Datei in einem beschreibbaren Verzeichnis (wird zum Schreiben von Testzielwarnungen verwendet) optional
TESTBRIDGE_TEST_ONLY Wert von --test_filter, falls angegeben optional
TZ UTC required
USER Wert von getpwuid(getuid())->pw_name required
XML_OUTPUT_FILE Speicherort der XML-Ausgabedatei mit den Testergebnissen. Das XML-Schema basiert auf dem JUnit-Testschema. optional
BAZEL_TEST Gibt an, dass die ausführbare Datei von bazel test ausgeführt wird required

Die Umgebung kann zusätzliche Einträge enthalten. Tests sollten nicht von der Präsenz, der Abwesenheit oder dem Wert anderer Umgebungsvariablen abhängen.

Das anfängliche Arbeitsverzeichnis ist $TEST_SRCDIR/$TEST_WORKSPACE.

Die aktuelle Prozess-ID, die Prozessgruppen-ID, die Sitzungs-ID und die übergeordnete Prozess-ID sind nicht angegeben. Dabei kann es sich um einen Leiter von Prozessgruppen oder einen Sitzungsleiter handeln. Dieser Prozess kann ein Steuerterminal haben oder nicht. Der Prozess kann null oder mehr untergeordnete oder nicht ausgebaute untergeordnete Prozesse haben. Der Prozess sollte nicht mehrere Threads enthalten, wenn der Testcode die Kontrolle gewinnt.

Der Dateideskriptor 0 (stdin) kann gelesen werden, aber die angehängten Elemente sind nicht angegeben. Tests dürfen nicht daraus lesen. Die Beschreibungen für die Dateien 1 (stdout) und 2 (stderr) können nur geschrieben werden, sind aber nicht festgelegt. Es kann ein Terminal, ein senkrechter Strich, eine normale Datei oder etwas anderes sein, in das Zeichen geschrieben werden können. Möglicherweise teilen sie einen Eintrag in der geöffneten Dateitabelle, d. h., sie können nicht separat suchen. Tests sollten keine anderen offenen Dateideskriptoren übernehmen.

Der Anfangstext muss 022 oder 027 lauten.

Es dürfen keine Wecker oder Intervall-Timer ausstehend sein.

Die anfängliche Maske mit blockierten Signalen muss leer sein. Für alle Signale wird die Standardaktion festgelegt.

Die anfänglichen Ressourcenbeschränkungen, sowohl „soft“ als auch „hart“, sollten so festgelegt sein:

Ressource Limit
RLIMIT_AS Unbegrenzt
RLIMIT_CORE ohne Angabe
RLIMIT_CPU Unbegrenzt
RLIMIT_DATA Unbegrenzt
RLIMIT_FSIZE Unbegrenzt
RLIMIT_LOCKS Unbegrenzt
RLIMIT_MEMLOCK Unbegrenzt
RLIMIT_MSGQUEUE ohne Angabe
RLIMIT_NICE ohne Angabe
RLIMIT_NOFILE mindestens 1.024
RLIMIT_NPROC ohne Angabe
RLIMIT_RSS Unbegrenzt
RLIMIT_RTPRIO ohne Angabe
RLIMIT_SIGPENDING ohne Angabe
RLIMIT_STACK unbegrenzt oder 2044 KB <= rlim <= 8192 KB

Die anfänglichen Prozesszeiten (wie von times() zurückgegeben) und die Ressourcennutzung (wie von getrusage() zurückgegeben) sind nicht angegeben.

Die ursprüngliche Richtlinie und Priorität für die Planung sind nicht angegeben.

Rolle des Hostsystems

Zusätzlich zu den Aspekten des Nutzerkontexts unter direkter Kontrolle des Test-Ausführers muss das Betriebssystem, auf dem Tests ausgeführt werden, bestimmte Eigenschaften erfüllen, damit ein Testlauf gültig ist.

Dateisystem

Das von einem Test beobachtete Stammverzeichnis kann das tatsächliche Stammverzeichnis sein.

/proc wird bereitgestellt.

Alle Build-Tools müssen an den absoluten Pfaden unter /usr vorhanden sein, die von einer lokalen Installation verwendet werden.

Pfade, die mit /home beginnen, sind möglicherweise nicht verfügbar. Tests sollten auf solche Pfade nicht zugreifen.

/tmp kann beschreibbar sein, aber diese Pfade sollten in Tests nicht verwendet werden.

Bei den Tests darf nicht davon ausgegangen werden, dass ein konstanter Pfad für die ausschließliche Verwendung verfügbar ist.

Bei den Tests darf nicht davon ausgegangen werden, dass für jedes bereitgestellte Dateisystem die Zeitangaben aktiviert sind.

Nutzer und Gruppen

Das Stammverzeichnis des Nutzers, „none“ und „unittest“ müssen vorhanden sein. Die Gruppen „root“, „none“ und „eng“ müssen vorhanden sein.

Tests müssen als Nicht-Root-Nutzer ausgeführt werden. Die tatsächlichen und die gültigen Nutzer-IDs müssen gleich sein, ebenso wie die Gruppen-IDs. Ist dies nicht der Fall, sind die aktuelle Nutzer-ID, Gruppen-ID, der Nutzername und der Gruppenname nicht angegeben. Der Satz ergänzender Gruppen-IDs ist nicht angegeben.

Die aktuelle Nutzer-ID und Gruppen-ID müssen die entsprechenden Namen haben, die mit getpwuid() und getgrgid() abgerufen werden können. Dasselbe gilt möglicherweise für ergänzende Gruppen-IDs.

Der aktuelle Nutzer muss ein Basisverzeichnis haben. Es kann nicht beschreibbar werden. Tests dürfen nicht versuchen, in diese zu schreiben.

Netzwerk

Der Hostname ist nicht angegeben. Kann einen Punkt enthalten oder nicht. Beim Auflösen des Hostnamens muss eine IP-Adresse des aktuellen Hosts angegeben werden. Außerdem müssen die Probleme behoben werden, die nach dem ersten Punkt behoben wurden. Der Hostname localhost muss aufgelöst werden.

Andere Ressourcen

Tests werden mindestens ein CPU-Kern gewährt. Andere sind möglicherweise verfügbar, aber das ist nicht garantiert. Andere Leistungsaspekte dieses Kerns sind nicht festgelegt. Sie können die Reservierung auf eine höhere Anzahl von CPU-Kernen erhöhen, indem Sie einer Testregel das Tag cpu:n" (n ist eine positive Zahl). Wenn eine Maschine weniger CPU-Kerne hat als angefordert, wird der Test von Istio dennoch ausgeführt. Wenn für einen Test Fragmentierung verwendet wird, reserviert jedes einzelne Shard die Anzahl der hier angegebenen CPU-Kerne.

Tests können Unterprozesse erstellen, aber keine Gruppen oder Sitzungen.

Die Anzahl der Eingabedateien, die für einen Test verwendet werden können, ist begrenzt. Dieses Limit kann sich ändern, liegt jedoch derzeit im Bereich Zehntausender Eingaben.

Datum und Uhrzeit

Uhrzeit und Datum sind nicht angegeben. Die Zeitzone des Systems ist nicht angegeben.

X Windows ist möglicherweise nicht verfügbar. Tests, die einen X-Server benötigen, sollten Xvfb starten.

Interaktion mit dem Dateisystem testen

Alle in Testtestvariablen angegebenen Dateipfade verweisen auf eine beliebige Stelle im lokalen Dateisystem, sofern nicht anders angegeben.

Tests sollten Dateien nur in den Verzeichnissen erstellen, die von $TEST_TMPDIR und $TEST_UNDECLARED_OUTPUTS_DIR (sofern festgelegt) angegeben werden.

Diese Verzeichnisse sind anfangs leer.

Tests dürfen diese Verzeichnisse nicht entfernen, ändern oder anderweitig ändern.

Diese Verzeichnisse können symbolische Links sein.

Der Dateisystemtyp $TEST_TMPDIR/. ist nicht angegeben.

Tests können auch Teildateien in das $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR-Element schreiben, um nicht deklarierte Ausgabedateien zu kennzeichnen.

In seltenen Fällen wird ein Test gezwungen, Dateien in /tmp zu erstellen. Beispielsweise ist für Pfadlängenlimits für Unix-Domain-Sockets in der Regel das Socket unter /tmp erstellt. Memcache kann solche Dateien nicht verfolgen. Der Test selbst muss vorsichtig sein, eindeutige Pfade verwenden, um einen Konflikt mit anderen, gleichzeitig laufenden Tests und Nicht-Testprozessen zu vermeiden, und die in /tmp erstellten Dateien bereinigen.

Einige beliebte Test-Frameworks wie JUnit4 TemporaryFolder oder Go TempDir bieten eigene Möglichkeiten, um ein temporäres Verzeichnis unter /tmp zu erstellen. Diese Test-Frameworks enthalten Funktionen, mit denen Dateien in /tmp bereinigt werden. Sie können sie also verwenden, auch wenn sie Dateien außerhalb von TEST_TMPDIR erstellen.

Für Tests muss der Mechanismus runfiles oder andere Teile der Ausführungsumgebung verwendet werden, die speziell für die Bereitstellung von Eingabedateien vorgesehen sind.

Tests dürfen nicht auf andere Ausgaben des Build-Systems unter Pfaden zugreifen, die aus dem Speicherort ihrer eigenen ausführbaren Datei abgeleitet werden.

Es ist nicht angegeben, ob die Runfiles-Baum reguläre Dateien, symbolische Links oder eine Mischung enthält. Der Runfiles-Baum enthält möglicherweise Symlinks zu Verzeichnissen. Für Tests sollte es sich nicht um Pfade handeln, die ..-Komponenten in der Ausführungsdatei-Baum enthalten.

Es darf kein Verzeichnis, keine Datei und kein symlink in der Ausführungsstruktur enthalten sein (einschließlich Pfade, die durch Symlinks verlaufen). Das anfängliche Arbeitsverzeichnis sollte daher nicht beschreibbar sein. Bei einem Test darf nicht davon ausgegangen werden, dass ein Teil der Ausführungsdateien beschreibbar ist oder dem aktuellen Nutzer gehört (z. B. chmod und chgrp).

Die Ausführungsdateistruktur (einschließlich Pfade, die symlinks durchlaufen) darf sich während der Testausführung nicht ändern. Übergeordnete Verzeichnisse und Dateisystembereitstellungen dürfen sich in keiner Weise ändern. Sie beeinträchtigen das Ergebnis der Auflösung eines Pfads in der Baumstruktur „Runfiles“.

Zum Beenden eines vorzeitigen Beendens kann ein Test eine Datei unter dem von TEST_PREMATURE_EXIT_FILE angegebenen Pfad erstellen und beim Beenden der Datei entfernen. Wenn {5/} nach Abschluss des Tests die Datei sieht, wird angenommen, dass er vorzeitig beendet wurde.

Tag-Konventionen

Einige Tags in den Testregeln haben eine besondere Bedeutung. Weitere Informationen findest du im Bazel Build Encyclopedia on the tags-Attribut.

Tag Bedeutung
exclusive keinen anderen Test gleichzeitig ausführen
external Test hat eine externe Abhängigkeit; Test-Caching deaktivieren
large test_suite-Konvention; Suite großer Tests
manual * Fügen Sie das Testziel nicht in Platzhalter-Zielmustern wie :..., :* oder :all ein
medium test_suite-Konvention; Suite mittlerer Tests
small test_suite-Konvention; Suite kleiner Tests
smoke test_suite-Konvention; bedeutet, dass sie ausgeführt werden soll, bevor Codeänderungen in das Versionsverwaltungssystem übertragen werden

Dateien ausführen

Im folgenden Beispiel wird davon ausgegangen, dass es eine *_binary()-Regel mit dem Label //foo/bar:unittest und eine Laufzeitabhängigkeit der Regel //deps/server:server gibt:

Ort

Das Runfiles-Verzeichnis für ein Ziel //foo/bar:unittest ist das Verzeichnis $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. Dieser Pfad wird als runfiles_dir bezeichnet.

Abhängigkeiten

Das Verzeichnis „runfiles“ ist als Abhängigkeit der Kompilierungszeit der Regel *_binary() deklariert. Das Runfiles-Verzeichnis selbst richtet sich nach den BUILD-Dateien, die sich auf die Regel *_binary() oder auf eine der Kompilier- oder Laufzeitabhängigkeiten auswirken. Änderungen an Quelldateien wirken sich nicht auf die Struktur des Verzeichnisses „runfiles“ aus und lösen daher keine Neuerstellung aus.

Inhalt

Das Verzeichnis „runfiles“ enthält Folgendes:

  • Symlinks zu Laufzeitabhängigkeiten: Jede OutputFile- und CommandRule-Regel, die eine Laufzeitabhängigkeit der *_binary()-Regel ist, wird durch einen Symlink im Runfiles-Verzeichnis dargestellt. Der Name des Symlinks lautet $(WORKSPACE)/package_name/rule_name. So lautet der Symlink für den Server beispielsweise $(WORKSPACE)/deps/server/server und der vollständige Pfad $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. Das Ziel von symlink ist die OutputFileName()-Datei der OutputFile oder CommandRule als absoluter Pfad. Das Ziel des Symlinks könnte also $(WORKSPACE)/linux-dbg/deps/server/42/server sein.
  • Symlinks zu untergeordneten Ausführungen: Für jede *_binary()-Z, die eine Laufzeitabhängigkeit von *_binary() C ist, gibt es einen zweiten Link im Runfiles-Verzeichnis von C zu den Ausführungsdateien von Z. Der Name des Symlinks lautet $(WORKSPACE)/package_name/rule_name.runfiles. Das Ziel des symlink-Elements ist das Verzeichnis „runfiles“. Alle Unterprogramme haben beispielsweise einen gemeinsamen Runfiles-Verzeichnis.