Häufig gestellte Fragen

Sollte ich mein Paket testen?

Natürlich sollten Sie das!

Wie kann ich Hilfe erhalten?

Verwenden Sie den Kanal #fedora-ci auf Matrix.

Warum nicht auf %check setzen?

%check und die Tests der CI-Pipeline ergänzen sich. %check ermöglicht zwar die Durchführung verschiedener Prüfungen zur Build-Zeit, erkennt aber keine fehlenden Anforderungen, Konfigurationsdateien oder ähnliche Probleme, die die CI-Pipeline testen und finden kann. Man könnte %check als Unit-Test (wobei die Unit das Paket ist) im Gegensatz zu Integrationstests betrachten, die die gesamte Distribution testen, so wie wir sie an unsere Benutzer verteilen. Die CI-Pipeline findet daher Integrationsfehler, die der %check-Abschnitt nicht aufspüren kann.

Wo soll ich meine Tests ablegen?

Es gibt verschiedene Möglichkeiten, den Testcode zu speichern. Hier sind einige der wichtigsten Vor- und Nachteile der einzelnen Ansätze: Testcode im dist git rpms Namespace wird zusammen mit den Spec-Dateien verzweigt und kann so die Funktionalität genau abbilden. Tests, die in mehreren Komponenten oder Betriebssystemversionen verwendet werden, können im dist git test Namespace gespeichert werden, um den Testcode gemeinsam zu nutzen und den Wartungsaufwand zu minimieren. Das Abrufen von Tests aus einem Upstream-Projekt-Git ist ebenfalls möglich und wird von den standard-test-roles (Source-Rolle) unterstützt. Um unerwartete Testfehler aufgrund von Upstream-Änderungen zu vermeiden, ist es manchmal besser, auf einen bestimmten Commit anstatt auf einen Branch zu verweisen. Tests, die in make check aktiviert sind, werden in einer anderen Umgebung (Buildroot) ausgeführt. Dies ist gut für Unit-Tests, wird aber für neue Tier-1-Testabdeckung nicht empfohlen. Aktivieren Sie 'make check' in tests.yml nur, wenn Sie installierte RPM-Pakete testen.