autopkgtest: pruebas automáticas para paquetes¶
DEP 8 specification define cómo se pueden integrar fácilmente pruebas automáticas en los paquetes. Para integrar una prueba en un paquete, todo lo que necesita hacer es:
añadir lo siguiente a la sección Source de debian/control:
XS-Testsuite: autopkgtest
añadir un archivo de nombre debian/tests/control que especifique los requisitos para el banco de pruebas,
añadir las pruebas en debian/tests/.
Requisitos del banco de pruebas¶
En debian/tests/control se especifica lo que se espera del banco de pruebas. Así, por ejemplo, debe recoger todos los paquetes necesarios para las pruebas, si el banco de pruebas falla durante la compilación o si hacen falta permisos de root.`DEP 8 specification`_ recoge todas las opciones disponibles.
Más adelante vamos a ver el paquete fuente glib2.0. En un caso muy simple el archivo podría tener la siguiente forma:
Tests: build
Depends: libglib2.0-dev, build-essential
Para la prueba de debian/tests/build esto se aseguraría que los paquetes libglib2.0-dev y build-essential están instalados.
Nota
Puede usar @ en la línea Depends para indicar que desea que estén instalados todos los paquetes que son compilados por el paquete fuente en cuestión.
La prueba real¶
La prueba asociada al ejemplo anterior podría ser:
#!/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"
Aquí una porción de código C muy simple se escribe en un directorio temporal. Luego es compilada con las bibliotecas del sistema (usando los marcadores y rutas de bibliotecas proporcionadas por pkg-config). Luego el binario compilado, que simplemente prueba algunas partes de la funcionalidad del núcleo de glib, se ejecuta.
Aunque esta prueba es muy pequeña y básica, prueba un buen número de componentes del sistema. Esto puede ayudar a descubrir de forma temprana incidencias críticas.
Ejecutando la prueba¶
El script de prueba se puede ejecutar fácilmente por sí mismo, pero si quiere asegurarse de que el banco de pruebas está correctamente configurado, debería usar adt-run del paquete autopkgtest para ejecutarlo. La forma más sencilla de hacerlo es ejecutar esta orden en el árbol fuente:
sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null
La desventaja de este enfoque es que se prueba en local, pero no puede asegurarse que vaya a funcionar en un entorno mínimo. Por ejemplo será difícil asegurar que todos los paquetes requeridos estén instalados para las pruebas. Con lp:auto-package-testing contamos con una herramienta de pruebas más completa. Esta utiliza una máquina virtual totalmente limpia para realizar las pruebas. Para su configuración, en primer lugar instale las dependencias necesarias:
sudo apt-get install qemu-utils kvm eatmydata
Luego, obtenga el código fuente desde Launchpad:
bzr branch lp:auto-package-testing
cd auto-package-testing
And provision a Saucy AMD64 system:
./bin/prepare-testbed -r saucy amd64
This command will create a pristine Saucy AMD64 VM from a cloud image. To run the tests, simply run:
./bin/run-adt-test -r saucy -a amd64 \
-S file:///tmp/glib2.0-2.35.7/ glib2.0
Esto usaría el paquete fuente de /tmp/glib2.0-2.35.7/` y ejecutaría las pruebas de este árbol contra el paquete ``glib2.0 del archivo. La opción -S también soporta esquemas para bzr, git y fuentes apt. Si solo indica un fuente con -S pero no indica un nombre de paquete, en lugar de eso se compilará la rama y se instalarán los binarios resultantes de esa compilación. Esto es útil si quiere ejecutar las pruebas sobre una versión más moderna que la empaquetada en Ubuntu, o si el paquete no está en absoluto en Ubuntu. Si usa el marcador -k puede iniciar sesión en la máquina virtual después de que se completen las pruebas. Esto hace que sea muy sencillo depurar los problemas.
auto-package-testing documentation contiene mucha más información valiosa sobre otras opciones de prueba.
Más ejemplos¶
Esta lista no es completa, pero podría ayudarle a hacer una mejor idea de cómo están implementadas y cómo se usan las pruebas automatizadas en Ubuntu.
- libxml2 tests son muy parecidos. También realizan una generación de una prueba a partir de una porción de código C sencilla y la ejecutan.
- gtk+3.0 tests también realiza una comprobación de compilación/enlace/ejecución en la prueba «build». Hay una prueba adicional «python3-gi» que verifica que la biblioteca GTK es accesible también mediante introspección.
- En ubiquity tests se ejecuta en conjunto de pruebas de aguas arriba.
- gvfs tests realiza pruebas exhaustivas de su funcionalidad y son muy interesantes porque emulan el uso de CDs, Samba, DAV y otras cosas.
Infraestructura de Ubuntu¶
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.
Aunque Debian no tiene todavía una infraestructura de pruebas automáticas, se deberían enviar igualmente a Debian, ya que DEP-8 es una especificación de Debian y sus desarrolladores o usuarios pueden ejecutar las pruebas manualmente.
Los paquetes en Debian con una cabecera de conjunto de pruebas también serán añadidos automáticamente cuando se sincronicen con Ubuntu.
Llevando la prueba a Ubuntu¶
El proceso de enviar un autopkgtest para un paquete es muy parecido a fixing a bug in Ubuntu. En esencia debe simplemente:
- ejecutar bzr branch ubuntu:<packagename>,
- editar el archivo debian/control para activar las pruebas,
- añadir el directorio debian/tests.
- escribir el debian/tests/control basado en`DEP 8 Specification`_,
- añadir sus casos de prueba a debian/tests,
- confirmar los cambios, empujarlos a Launchpad, proponer una integración y hacer que la revisen igual que cualquier otra mejora de un paquete fuente.
Lo que puede hacer¶
El equipo de ingeniería de Ubuntu ha preparado una lista de casos de prueba requeridos, donde los paquetes que necesitan pruebas se colocan en diferentes categorías. Aquí puede encontrar ejemplos de esas pruebas y asignarlas fácilmente a usted.
Si encuentra algún problema, puede unirse al canal de IRC #ubuntu-quality para ponerse en contacto con desarrolladores que pueden ayudarle.