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 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¶
While the test script can be easily executed on its own, it is strongly
recommended to actually use autopkgtest
from the autopkgtest
package for
verifying that your test works; otherwise, if it fails in the Ubuntu Continuous
Integration (CI) system, it will not land in Ubuntu. This also avoids cluttering
your workstation with test packages or test configuration if the test does
something more intrusive than the simple example above.
The README.running-tests
(online version) 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 Archievs 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 erstelle eine Testumgebung mit:
autopkgtest-buildvm-ubuntu-cloud -v
(Please see its manpage and --help
output for selecting different releases,
architectures, output directory, or using proxies). This will build e. g.
adt-trusty-amd64-cloud.img
.
Then run the tests of a source package like libpng
in that QEMU image:
autopkgtest libpng --- qemu adt-trusty-amd64-cloud.img
The Ubuntu CI system runs packages with only selected packages from
-proposed
available (the package which caused the test to be run); to
enable that, run:
autopkgtest libpng -U --apt-pocket=proposed=src:foo --- qemu adt-release-amd64-cloud.img
or to run with all packages from -proposed
:
autopkgtest libpng -U --apt-pocket=proposed --- qemu adt-release-amd64-cloud.img
The autopkgtest
manpage has a lot more valuable information on other
testing options.
4.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 führen auch eine Testerstellung aus ein bisschen einfachem C-Code durch und führen sie aus.
- The gtk+3.0 tests also do a compile/link/run check in the „build“ test. There is an additional „python3-gi“ test which verifies that the GTK library can also be used through introspection.
- In den ubiquity Tests wird die Upstream Testsammlung ausgeführt.
- The gvfs tests have comprehensive testing of their functionality and are very interesting because they emulate usage of CDs, Samba, DAV and other bits.
4.5. Ubuntu Infrastruktur¶
Packages which have autopkgtest
enabled will have their tests run whenever
they get uploaded or any of their dependencies change. The output of
automatically run autopkgtest tests can be viewed on the web and is
regularly updated.
Debian also uses autopkgtest
to run package tests, although currently only
in schroots, so results may vary a bit. Results and logs can be seen on
http://ci.debian.net. So please submit any test fixes or new tests to Debian as
well.
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:
- Führe
bzr branch ubuntu:<Paketname>
aus, - 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 du machen kannst¶
The Ubuntu Engineering team put together a list of required test-cases, where packages which need tests are put into different categories. Here you can find examples of these tests and easily assign them to yourself.
Sollten Probleme auftreten, kann man auf dem #ubuntu-quality IRC Kanal Kontakt zu Entwicklern herstellen, die helfen können.