Ubuntu logo

Developer

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

The downside of this approach is that you test it locally, but can’t ensure that this will work in a minimal environment. For example will it be hard to ensure that all the required packages are installed for the tests. With lp:auto-package-testing we have a more comprehensive testing tool. It uses a pristine virtual machine to run the tests. To set it up, firstly install the needed dependencies:

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 Raring AMD64 system:

./bin/prepare-testbed -r raring amd64

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

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

This would use the source package in /tmp/glib2.0-2.35.7/ and run the tests from this tree against the package glib2.0 from the archive. The option -S also supports schemes for bzr, git, and apt sources. If you only specify a source with -S but do not specify a package name, this will instead build the branch and install the binaries from that build; this is useful if you want to run tests on a newer version than the one packaged in Ubuntu, or the package is not in Ubuntu at all. If use the -k flag you can log into the virtual machine after the tests were run. This makes it very easy to debug issues.

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

Los paquetes que tienen activado autopkgtest ejecutarán sus pruebas siempre que se suban o cambie alguna de sus dependencias inversas. La salida de automatically run autopkgtest tests se puede ver en la web y se actualiza de forma regular.

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.