3. autopkgtest : tests automatiques pour les paquets¶
La spécification DEP 8 définit la façon dont les tests automatiques peuvent être très facilement intégrés dans les paquets. Pour intégrer un test dans un paquet, tout ce que vous devez faire est de :
ajoutez ce qui suit à la section Source dans debian/control:
XS-Testsuite: autopkgtest
ajoutez un fichier appelé debian/tests/control qui spécifie les exigences pour le banc d’essai,
ajoutez les tests dans debian/tests/.
3.1. Exigences du banc d’essai¶
Dans debian/tests/control vous spécifiez ce que vous attendez du banc d’essai. Ainsi, par exemple, vous listez tous les paquets nécessaires pour les tests, si le banc d’essai se casse lors de la construction ou si les autorisations root sont nécessaires. La spécification DEP 8 répertorie toutes les options disponibles.
Ci-dessous, nous voyons un aperçu du paquet source glib2.0. Dans un cas très simple, le fichier devrait ressembler à ceci:
Tests: build
Depends: libglib2.0-dev, build-essential
Pour le test dans debian/tests/build, cela permettrait de s’assurer que les paquets libglib2.0-dev et build-essential sont installés.
Note
Vous pouvez utiliser @ de la ligne Depends pour indiquer que vous souhaitez tous les paquets installés construits par la paquet source en question.
3.2. Les tests réels¶
Le test accompagnant l’exemple ci-dessus pourrait être :
#!/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"
Ici, un morceau très simple de code C est écrit dans un répertoire temporaire. C’est ensuite compilé avec les bibliothèques système (en utilisant les drapeaux et chemins des bibliothèques fournis par pkg-config). Ensuite, le binaire compilé, qui fait juste appel à quelques fonctionnalités glib de parties du noyau, est exécuté.
Bien que ce test soit très petit et basique, il teste un grand nombre de composantes du noyau d’un système. Cela peut aider à découvrir plus tôt des problèmes critiques.
3.3. Exécution du test¶
Le script de test peut être facilement exécuté tout seul, mais si vous voulez être sûr que le banc d’essai est correctement configuré, il est préférable d’utiliser adt-run depuis le paquet autopkgtest pour exécuter le test. La plus simple façon de le faire est de lancer cette commande dans l’arbre source:
sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null
L’inconvénient de cette approche est que vous le testez en local, mais vous ne pouvez pas être sûr que cela fonctionnera dans un environnement minimal. Il sera par exemple difficile de s’assurer que tous les paquets requis sont installés pour les tests. Avec lp:auto-package-testing nous avons un outil de test bien plus complet. Il utilise une machine virtuelle toute fraîche pour exécuter les tests. Pour le paramétrer, commencez par installer les dépendances nécessaires:
sudo apt-get install qemu-utils kvm eatmydata
Ensuite, récupérez le code source sur Launchpad:
bzr branch lp:auto-package-testing
cd auto-package-testing
Et provisionnez un système Saucy AMD64:
./bin/prepare-testbed -r saucy amd64
Cette commande va créer une Machine Virtuelle vierge AMD 64 Saucy depuis une image issue du nuage. Pour lancer les tests, exécutez simplement :
./bin/run-adt-test -r saucy -a amd64 \
-S file:///tmp/glib2.0-2.35.7/ glib2.0
Cela utilisera le paquet source dans /tmp/glib2.0-2.35.7/ et lancera les tests de cet arbre sur le paquet glib2.0 de l’archive. L’ option -S gère aussi les schémas pour les sources bzr, git et apt. Si vous spécifiez seulement une source avec -S sans spécifier le nom du paquet, à la place, cela construira la branche et installera les binaires construits ; C’est plus pratique si vous voulez lancer les tests sur une version plus récente que celle empaquetée dans Ubuntu, ou si le paquet n’est pas du tout dans Ubuntu. Si vous utilisez le drapeau -k vous pouvez vous connecter dans une machine virtuelle après l’exécution des tests. Cela rend le débogage des problèmes très facile.
La documentation auto-package-testing a beaucoup plus d’informations utiles sur les autres options de tests.
3.4. Exemples complémentaires¶
Cette liste n’est pas exhaustive mais elle peut vous aider à mieux comprendre comment les tests automatiques sont implémentés et utilisés dans Ubuntu.
Les tests libxml2 sont très similaires. Ils effectuent aussi un test de compilation d’un simple morceau de code C et l’exécutent.
Les tests gtk +3.0 font également une compilation/link/run vérifier dans le dossier “build” test. Il y a un test supplémentaire “python3-gi” qui vérifie que la bibliothèque GTK peut également être utilisé par l’introspection.
Dans les tests ubiquity la suite de test en amont est exécutée.
Les tests gvfs ont un test complet de leur fonctionnalité et sont très intéressants car ils émulent l’utilisation de CD, Samba, DAV et autres bricoles.
3.5. infrastructure Ubuntu¶
Les paquets autorisés en autopkgtest seront testés à chaque téléchargement ou modification de leurs dépendances. Les produits des tests autopkgtest à exécution automatique peuvent être consultés sur internet et sont régulièrement mis à jour.
Bien que Debian n’a pas encore mis en place une infrastructure de test automatique, ils doivent encore être soumis à Debian, car DEP-8 est une spécification Debian et les développeurs ou les utilisateurs Debian peuvent toujours exécuter manuellement les tests.
Les paquets dans Debian avec un en-tête testsuite seront également ajoutés automatiquement quand ils sont synchronisés avec Ubuntu.
3.6. Faire passer le test dans Ubuntu¶
Le processus de soumission d’un autopkgtest pour un paquet est très similaire à corriger un bogue dans Ubuntu. Essentiellement, il vous suffit de :
exécuter bzr branch ubuntu:<nomdupaquet>,
modifier debian/control pour activer les tests,
ajouter le répertoire debian/tests,
écrire le debian/tests/control basé sur la spécification DEP 8,
ajouter votre cas de test(s) à debian/tests,
valider vos modifications, les téléverser vers Launchpad, proposer une fusion et obtenir son examen, exactement comme pour toute autre amélioration dans un paquet source.
3.7. Ce que vous pouvez faire¶
L’équipe d’ingénierie Ubuntu a dressé une liste des cas nécessaires de test, où les paquets nécessitant d’être testés sont placés dans différentes catégories. Ici vous pouvez trouver des exemples de ces tests et vous les attribuer aisément.
Si vous rencontrez des problèmes, vous pouvez rejoindre le canal IRC #ubuntu-quality pour entrer en contact avec les développeurs qui peuvent vous aider.