# 3. autopkgtest: Automatische Tests für Pakete

Die DEP 8-Spezifikation legt fest, wie automatische Tests sehr einfach in Pakete eingebunden werden können. Um einen Test in ein Paket einzubinden, müssen Sie nur folgendes machen:

- fügen Sie folgendes zum Abschnitt “Source” in `debian/control` hinzu:

      XS-Testsuite: autopkgtest

- erstellen Sie eine Datei namens `debian/tests/control`, die die Anforderungen für die Testumgebung festlegt,

- fügen Sie die Tests in `debian/tests/` ein.

## 3.1. Anforderungen für die Testumgebung

In `debian/tests/control` legen Sie fest, welche Anforderungen die Testumgebung erfüllen muss. Sie können zum Beispiel alle Pakete auflisten, die für die Tests benötigt werden, oder angeben, ob die Testumgebung beim Erstellen des Pakets beschädigt wird oder ob `root`-Rechte benötigt werden. Die DEP 8 specification listet alle verfügbaren Optionen auf.

Im Folgenden schauen uns das Quellpaket `glib2.0` an. Im einfachsten Fall sieht die Datei so aus:

    Tests: build
    Depends: libglib2.0-dev, build-essential

Das stellt für den Test `debian/tests/build` sicher, dass die Pakete `libglib2.0-dev` und `build-essential` installiert sind.

Bemerkung

Sie können in der `Depends`-Zeile `@` benutzen, um festzulegen, dass Sie alle Pakete installiert haben wollen, die aus dem jeweiligen Quellpaket erzeugt werden.

## 3.2. Die eigentlichen Tests

Der passende Test für das obige Beispiel könnte folgender sein:

    #!/bin/sh
    # autopkgtest check: Build and run a program against glib, to verify that the
    # headers and pkg-config file are installed correctly
    # (C) 2012 Canonical Ltd.
    # Author: Martin Pitt <martin.pitt@ubuntu.com>

    set -e

    WORKDIR=$(mktemp -d)
    trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
    cd $WORKDIR
    cat <<EOF > glibtest.c
    #include <glib.h>

    int main()
    {
        g_assert_cmpint (g_strcmp0 (NULL, "hello"), ==, -1);
        g_assert_cmpstr (g_find_program_in_path ("bash"), ==, "/bin/bash");
        return 0;
    }
    EOF

    gcc -o glibtest glibtest.c `pkg-config --cflags --libs glib-2.0`
    echo "build: OK"
    [ -x glibtest ]
    ./glibtest
    echo "run: OK"

An dieser Stelle wird ein sehr einfaches Stück C-Code in ein temporäres Verzeichnis geschrieben. Dies wird mit den Systembibliotheken übersetzt (wobei die Flags und Bibliothekpfade benutzt werden, wie sie uns von pkg-config geliefert werden). Dann wird der resultierende Binär-Code ausgeführt, der grundlegende Funtionen in glib testet.

Obwohl es sich um einen kleinen und simplen Test handelt, werden eine größere Anzahl von Systemkomponenten getestet. Dies hilft kritische Fehler früher zu entdecken.

## 3.3. Den Test ausführen

Das Test-Skript kann selbst ausgeführt werden, aber um sicherzustellen, dass der Test auch in der Testumgebung zufriedenstellend abläuft, bietet es sich an “adt-run” (im Paket “autopkgtest”) zu verwenden, um diesen Test auszuführen. Der einfachste Weg dazu ist diesen Befehl im Quellpfad auszuführen.

    sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null

Der Nachteil dieser Herangehensweise ist, dass du es zwar lokal testen kannst, aber nicht sicherstellen kannst, dass es in einer minimalen Umgebung funktioniert. Zum Beispiel ist es schwierig festzustellen, ob alle benötigten Pakete für die Versuche installiert sind. Mit ‘lp:auto-package-testing’ haben wir ein umfangreiches Hilfsmittel, welches auf Basis einer unveränderten virtuellen Machine die Tests durchführt. Um es einzurichten, musst du zuerst die benötigten Abhängigkeiten installieren:

    sudo apt-get install qemu-utils kvm eatmydata

Dann besorge dir den Quellcode von Launchpad:

    bzr branch lp:auto-package-testing
    cd auto-package-testing

And provision a Trusty AMD64 system:

    ./bin/prepare-testbed -r trusty amd64

This command will create a pristine Trusty AMD64 VM from a cloud image. To run the tests, simply run:

    ./bin/run-adt-test -r trusty -a amd64 \
        -S file:///tmp/glib2.0-2.35.7/ glib2.0

Das würde das Quellpaket `/tmp/glib2.0-2.35.7/` auswählen und die Tests gegen das Paket `glib2.0` aus dem Archiv laufen lassen. Die Option `-S` unterstützt auch Quellen von bzr, git und apt. Wenn du nur eine Quelle mit `-S` festlegst, aber den Paketnamen nicht genauer bestimmst, wird diese Funktion stattdessen den Zweig aufbauen und die Binaries von dieser Version installieren; das ist nützlich wenn du Tests für ein neueres Paket durchführen willst als das welches in Ubuntu enthalten ist oder das Paket überhaupt nicht in Ubuntu existiert. Wenn du die Option `-k` setzt kannst du in die virtuelle Maschine wechseln nachdem die Tests durchgeführt wurden. Das macht es sehr einfach Fehler zu erkennen.

Die ‘auto-package-testing documentation’ hat viele andere wichtige Informationen für andere Testoptionen.

## 3.4. Weitere Beispiele

Diese Liste ist nicht vollständig, aber wird dir sicher einen guten Einblick geben wie automatisierte Testdurchläufe in Ubuntu implementiert und benutzt werden.

- Die libxml2 tests sind sehr ähnlich. Sie enthalten auch eine Test-Kompilierung eines Stücks C-Code und führen es aus.

- Der Test ‘gtk+3.0 tests’ erwirkt außerdem einen Kompilierungs-, Link- und Durchlaufstest im ‘’build’’ Test. Es gibt einen zusätzlichen “python3-gi”-Test, welcher sicherstellt, dass die GTK-Bibliothek auch durch “Introspection” benutzt werden kann.

- In den ubiquity tests wird die Test-Suite von Upstream (den Software-Autoren) ausgeführt.

- Die gvfs tests haben ausführliche Funktionalitätstests und sind sehr interessant, weil sie die Benutzung von CDs, Samba, DAV und anderen Dingen simulieren.

## 3.5. Ubuntu Infrastruktur

Pakete, welche `autopkgtest` aktiviert haben, werden jedes mal, wenn Sie hochgeladen werden oder eine Ihrer Abhängigkeiten sich ändert, einem Testlauf unterzogen. Die Ausgabe der automatisch laufenden autopkgtest-Tests können im Internet angesehen werden und werden regelmäßig aktualisiert.

Debian hat bisher noch keine Infrastruktur für Automatisches Testen, aber Tests sollten trotzdem nach Debian weitergeleitet werden, denn DEP-8 ist eine Debian-Spezifikation und Debian-Entwickler und -Nutzer können Tests immerhin manuell ausführen.

Pakete in Debian mit dem Testsuite-Header werden außerdem automatisch hinzugefügt, wenn sie nach Ubuntu gesynced werden.

## 3.6. Die Tests in Ubuntu bekommen

Der Prozess, um einen autopkgtest in Ubuntu einzubringen ist größtenteils identisch mit fixing a bug in Ubuntu. Im Prinzip muss man einfach:

- Führe `bzr branch ubuntu:<Paketname>` aus,

- bearbeiten Sie `debian/control` um die Tests zu aktivitieren,

- fügen Sie ein `debian/tests`-Verzeichnis hinzu,

- schreiben Sie die `debian/tests/control`-Datei, basierend auf der DEP 8 Specification,

- fügen Sie Ihre(n) Test(s) zu `debian/tests` hinzu,

- die Änderungen committen, sie nach Launchpad hochladen, und einen Merge vorschlagen, sie dann überprüfen lassen, genau wie jede andere Änderung an einem Quellpaket auch.

## 3.7. Was du machen kannst

Das Ubuntu Engineering Team hat eine Liste von list of required test-cases zusammengestellt, wo Pakete die Tests brauchen in verschiedene Kategorien aufgeteilt wurden. Hier kannst du eine Liste von Beispielen von Tests finden und das Schreiben der Tests Dir zuweisen.

Falls irgendwelche Probleme auftreten, kannst du dem #ubuntu-quality IRC channel beitreten, um in Kontakt mit den Entwicklern zu treten.