Ubuntu logo

Packaging Guide

4. autopkgtest: Automatische Tests für Pakete

Die DEP 8 Spezifikation definiert wie automatisches Testen sehr einfach in Paketen eingebunden werden kann. Alles was es braucht um einen Test in einem Paket einzubinden:

  • 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.

4.1. Anforderungen für die Testumgebung

In debian/tests/control wird festgelegt, was die Testumgebung leisten muss. Zum Beispiel werden alle für den Test benötigten Pakete aufgeführt, ob die Testumgebung während der Erstellung verloren geht oder ob root Privilegien gebraucht werden. Die DEP 8 Spezifikation listet alle möglichen Optionen auf.

Im Folgenden schauen wir 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.

4.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.

Während der Test selbst sehr klein und einfach ist, umfasst er doch eine Menge: Es wird sichergestellt, dass das -dev Paket alle nötigen Abhängigkeiten besitzt, dass von dem Paket funktionierende pkg-Konfigurationsdateien installiert werden, dass die Header und Bibliotheken richtig platziert werden, oder dass der Kompiler und Linker funktionieren. Das hilft dabei, kritische Fehler schon sehr früh aufzudecken.

4.3. Den Test ausführen

Während das Testskript leicht selbst ausgeführt werden kann, wird dringend empfohlen, autopkgtest aus dem autopkgtest Paket zu verwenden. Somit kann überprüft werden, dass Ihr Test funktioniert. In anderen Fällen wird es der Test wenn er im Ubuntu Continuous Integration (CI) System fehlschlägt, nicht in Ubuntu landen. Dies verhindet eben so, dass Ihre Workstation mit Testpaketen oder Testkonfiguration zugemüllt wird, wenn der Test etwas weiteres als das einfache Beispiel oben macht.

The README.running-tests documentation explains all available testbeds (schroot, LXD, QEMU, etc.) and the most common scenarios how to run your tests with autopkgtest, e. g. with locally built binaries, locally modified tests, etc.

Das Ubuntu CI-System benutzt den QEMU-Runner und führt alle Tests der Pakete in des Archivs aus, welche -proposed aktiviert haben. Um genau die selbe Umgebung zu reproduzieren, müssen zuerst die nötigen Pakten installiert werden:

sudo apt install autopkgtest qemu-system qemu-utils autodep8

Nun erstellen Sie eine Testumgebung mit:

autopkgtest-buildvm-ubuntu-cloud -v

(Bitte beachten Sie die Manpage und die --help Ausgabe zur Auswahl von verschiedenen Veröffentlichungen, Architekturen, Ausgabeverzeichnis oder die Nutzung von Proxies). Dies baut beispielsweise adt-trusty-amd64-cloud.img`.

Dann starte die Tests eines Quellpakets wie libpng in diesem QEMU-Abbild:

autopkgtest libpng -- qemu adt-trusty-amd64-cloud.img

Das Ubuntu CI System startet Pakete nur mit ausgewählten Paketen von -proposed die verfügbar sind (das Paket welches den Start des Tests auslöst); um dies zu aktivieren starten Sie:

autopkgtest libpng -U --apt-pocket=proposed=src:foo -- qemu adt-release-amd64-cloud.img

oder mit allen Paketen von -proposed laufen lassen:

autopkgtest libpng -U --apt-pocket=proposed -- qemu adt-release-amd64-cloud.img

Die autopkgtest Manpage beinhaltet eine Menge an weiteren wertvollen Informationen über andere Testoptionen.

4.4. Weitere Beispiele

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

  • Die libxml2 Tests sind sehr ähnlich. Sie führen auch eine Testerstellung aus ein bisschen einfachem C-Code durch und führen sie aus.

  • Die gtk+3.0 tests leisten auch einen Kompilier/Link/Start-Check im „build“ Test. Es gibt einen zusätzlichen „python3-gi“ Test welcher sicherstellt, dass die GTK Bibliothek auch über Introspektion genutzt werden kann.

  • In den ubiquity Tests wird die Upstream Testsammlung ausgeführt.

  • Die gvfs tests haben ausführliches Testen ihrer Funktionalität und sind sehr interessant, da die die Nutzung von CDs, Samba, DAV und anderen Teilen emulieren.

4.5. Ubuntu Infrastruktur

Pakete , die``autopkgtest`` aktiviert haben werden ihre Tests starten sobald sie hochgeladen werden oder eine ihrer Abhängigkeiten sich ändert. Die Ausgabe von automatically run autopkgtest tests kann im Web eingesehen werden und wird stetig aktualisiert.

Debian benutzt ebenfalls autopkgtest für Pakettests wobei dies momentan nur in schroots erfolgt. Somit können die Ergebnisse ein wenig variieren. Ergebnisse und Logs können auf http://ci.debian.net eingesehen werden. Bitte senden Sie daher jegliche Testbehebungen oder neue Tests gleichzeitig an Debian.

4.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:

  • bzr branch ubuntu:<Paketname> ausführen,

  • bearbeiten Sie debian/control um die Tests zu aktivitieren,

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

  • bearbeite debian/tests/control basierend auf der DEP 8 Spezifikation,

  • 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.

4.7. Was Sie machen können

Das Ubuntu Engineering Team hat eine Liste von benötigten Testfällen<requiredtests_> zusammengestellt wo Pakete, die Tests benötigen in verschiedene Kategorien gestellt werden. Hier finden Sie Beispiele dieser Tests und können sie sich selbst zuweisen.

Sollten Probleme auftreten, kann man auf dem #ubuntu-quality IRC Kanal Kontakt zu Entwicklern herstellen, die helfen können.