1. Die Test-Umgebung

Die Codebasis verfügt über Unit- und Integrationstests, die automatisch ausgeführt werden können, um sicherzustellen, dass das Programm wie vorgesehen funktioniert. Solche Tests werden oft geschrieben, um einen Fehler auszulösen und sicherzustellen, dass der Fehler entdeckt wird, wenn er in der Zukunft wieder auftaucht, aber auch um das Verhalten von Komponenten und Schnittstellen zu validieren.

Die Tests werden im Verzeichnis tests/ gesammelt. Die einzelnen Tests befinden sich in Unterverzeichnissen dieses Verzeichnisses. Die Tests sind in Verzeichnissen gruppiert.

2. Tests ausführen

Die Tests werden durch das Skript scripts/runtests ausgeführt, das während des Builds aus scripts/runtests.in erzeugt wird. Das Skript runtests sucht standardmäßig nach Tests, die unter tests/ ausgeführt werden sollen, kann aber eingeschränkt werden, um nur eine begrenzte Anzahl von Tests auszuführen, indem das Verzeichnis des Tests oder der Tests als Argument(e) angegeben wird.

Ein Beispiel, in dem nur die Tests in tests/lathe/ ausgeführt werden.
$ scripts/runtests tests/lathe/
Running test: tests/lathe
Runtest: 1 tests run, 1 successful, 0 failed + 0 expected, 0 skipped

Das Skript runtests sucht nach allen Dateien mit den Namen test, test.sh oder test.hal unterhalb der auf der Befehlszeile angegebenen Verzeichnisse oder unter tests/, wenn kein Befehlszeilenargument angegeben wird. Diese Dateien stehen für drei verschiedene Möglichkeiten, die Tests auszuführen.

Das Skript runtests akzeptiert die folgenden Argumente, siehe die Ausgabe von scripts/runtests -h für die maßgebliche Liste:

-n Temporäre Dateien bei erfolgreichen Tests nicht entfernen.
-s Stoppt nach jedem fehlgeschlagenen Test.
-p Stderr und Ergebnisdateien ausgeben.
-c Temporäre Dateien eines früheren Testlaufs entfernen.
-u Nur Tests ausführen, die normalen Benutzerzugriff erfordern.
-v Zeigt stdout und stderr an (normalerweise ist es versteckt).

3. Tests Schreiben

Vergewissern Sie sich, dass der Test auch ohne funktionierende X11-Anzeige erfolgreich durchgeführt werden kann, d.h. wenn die Umgebungsvariable DISPLAY nicht gesetzt ist.

  1. Erstellen Sie einen Ordner in tests/.

  2. Stellen Sie ein Testskript bereit.

  3. Werten Sie die Ausgabe mit einer der folgenden Optionen aus.

Dies sind die Dateien, die in dem Verzeichnis mit den einzelnen Tests berücksichtigt werden:

Testskript (nur eines von diesen drei)
Test

Ein Programm, das ausgeführt wird und dessen Exit-Code und Ausgabe entweder mit checkresult oder expected überprüft wird.

test.sh

Ein Bash-Skript, das ausgeführt wird und dessen Exit-Code und Ausgabe entweder mit checkresult oder expected überprüft wird.

test.hal

Ein HAL-Skript, das mit halrun -f test.hal ausgeführt wird und dessen Exit-Code und Ausgabe entweder mit checkresult oder expected überprüft wird.

Test Auswertung
expected (engl. für erwartet)

Eine Datei, deren Inhalt mit der Ausgabe der Testskripte verglichen wird. Ist die Testausgabe identisch mit dem Inhalt der erwarteten Datei, so ist der Test erfolgreich.

checkresult

Eine ausführbare Datei, um komplexere Überprüfungen durchzuführen als nur den Vergleich der Ausgabe eines Testskripts. Es erhält den Dateinamen des Testprogramms als Befehlszeilenargument. Der Exit-Code dieses Programms bestimmt das Ergebnis des Tests. Wenn sowohl expected als auch checkresult existieren, wird nur checkresult zur Validierung der Testausgabe herangezogen.

xfail

Wenn diese Datei existiert, wird ein Testfehler erwartet und führt nicht dazu, dass runtests mit einem Exit-Code zurückkehrt, der einen Fehler signalisiert.

überspringen

Wenn diese Datei existiert, wird der Test übersprungen und nicht ausgeführt.

control

Diese Datei kann verwendet werden, um bestimmte Anforderungen im Test zu kennzeichnen. Momentan kann die Verwendung von sudo markiert werden, und Tests, die sudo erfordern, können bei der Verwendung von runtests -u übersprungen werden. Um solche Anforderungen zu markieren, fügen Sie eine Zeile mit Restrictions: sudo zu dieser Datei hinzu.

4. Verschiedene Verfahren zum Testen

Es gibt verschiedene Möglichkeiten, einen Test zu strukturieren, je nachdem, was man testen möchte. Hier sind ein paar Ideen, wie man es machen kann.

4.1. Nicht-interaktive "GUI"

Wenn Sie einige Vorgänge in der Benutzeroberfläche testen möchten, ist es sinnvoll, eine benutzerdefinierte "GUI" zu schreiben, die die Vorgänge simuliert. Dies kann erreicht werden, indem ein normales LinuxCNC-Setup erstellt und der Wert [DISPLAY] DISPLAY auf ein Skript verwiesen wird, das die zum Testen des Verhaltens erforderlichen Operationen ausführt.

Beispiele für diesen Ansatz finden sich in tests/halui/jogging/ und tests/interp/subroutine-return/.

4.2. Aufzeichnen von HAL-Pin-Übergängen

Mit den HAL-Komponenten sampler und halsampler kann man eine HAL-Konfiguration einrichten und Pin-Einstellungen und -Änderungen sammeln und das Ergebnis in stdout (oder eine Datei) ausgeben. Das Endergebnis kann dann mit der erwarteten Ausgabe verglichen werden, um zu überprüfen, ob sich HAL wie erwartet verhält.

Beispiele für diesen Ansatz finden sich in tests/multiclick/ und tests/stepgen.2/.