3. autopkgtest: Teste automático para pacotes¶
O `DEP 8 specification`_define como o teste automático pode ser facilmente integrado dentro dos pacotes. Para integrar um teste dentro de um pacote tudo o que você precisa fazer é:
adicione o seguinte à seção Source em debian/control:
XS-Testsuite: autopkgtest
adicione um arquivo chamado debian/tests/control que especifica os requisitos para o testbed,
adicione os testes em debian/tests/.
3.1. Requisitos do Testbed¶
No debian/tests/control você especifica o que esperar do testbed. Por exemplo: você lista todos os pacotes requeridos para os testes, se o testbed falhar durante a compilação ou se permissões de root são necessárias. A DEP 8 specification lista todas as opções disponíveis.
Abaixo estamos vendo o pacote fonte do glib2.0. Em um caso muito simples, o arquivo se pareceria com isto:
Tests: build
Depends: libglib2.0-dev, build-essential
Para o teste em debian/tests/build isto deverá garantir que os pacotes libglib2.0-dev e build-essential estão instalados.
Nota
Você pode usar @ na linha Depends para indicar que você quer que todos os pacotes instalados sejam compilados pelo pacote fonte em questão.
3.2. Os testes reais¶
O teste que deve acompanhar o exemplo acima poderia 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"
Aqui um pedaço simples de código em C é escrito em um diretório temporário. Então este é compilado com bibliotecas do sistema (usando flags e caminhos de biblioteca providos por pkg-config). Em seguida o binário compilado, que apenas utiliza partes da funcionalidade do núcleo glib, é executado.
Embora este teste seja muito pequeno e básico, ele testa um grande número de componentes em um sistema. Isto pode ajudar a descobrir questões críticas antecipadamente.
3.3. Executando o teste¶
Este script de teste pode ser facilmente executado por conta própria, mas se você quiser ter certeza que o testbed está corretamente configurado, você pode utilizar adt-run do pacote autopkgtest para executar o teste. A maneira mais fácil de fazer isto é rodando o comando em seu diretório de origem:
sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null
A desvantagem dessa abordagem é que você testá-lo localmente, mas não pode garantir que isso vai funcionar em um ambiente mínimo. Por exemplo vai ser duro para garantir que todos os pacotes necessários estão instalados para os testes. Com lp:auto-package-testing temos uma ferramenta de teste mais abrangente. Ele usa uma máquina virtual para intocada executar os testes. Para configurá-lo, em primeiro lugar instalar as dependências necessárias
sudo apt-get install qemu-utils kvm eatmydata
Então, obter o código fonte do 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
Isto usaria o pacote fonte em /tmp/glib2.0-2.35.7/ e executaria os testes desta árvore com o glib2.0 a partir do arquivo. A opção -S também suporta esquemas para fontes bzr, git, e apt. Se você somente especificar uma fonte com -S, mas não especificar o nome do pacote, o ramo será compilado e os binários daquela compilação serão instalados; isto é útil se você quer executar testes em uma nova versão de um pacote no Ubuntu, ou se o pacote não estiver no Ubuntu. Se usar a opção -k, você pode entrar na máquina virtual após a execução dos testes. Isso torna mais fácil depurar problemas.
O auto-package-testing documentation tem muito mais informação valiosa sobre outras opções de teste
3.4. Outros exemplos¶
Esta lista não é completa, mas pode ajudá-lo a ter uma ideia melhor de como testes automatizados são implementados e usados no Ubuntu.
Os testes em libxml2 tests são muito similares. Eles também compilam um teste de um pedaço simples de código em C e o executam.
Os testes em gtk+3.0 tests também compilam/linkam/executam verificações no teste de compilação. Há um teste adicional “python3-gi” que verifica que a biblioteca GTK pode ser usada através de introspecção.
Nos testes do ubiquity a suíte de testes do upstream é executada.
Os testes em gvfs tests tem testes abrangentes de suas funcionalidades e são muito interessantes porque emulam uso de CDs, Samba, DAV e entre outros.
3.5. Infraestrutura do 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.
Enquanto o Debian ainda não tiver uma infra-estrutura de teste automatizado configurada, eles ainda devem ser submetidos ao Debian, uma vez que DEP-8 é uma especificação do Debian e os desenvolvedores Debian, ou usuários, ainda podem executar os testes manualmente.
Pacotes no Debian com um cabeçalho testsuite também serão adicionados automaticamente quando eles forem sincronizados com o Ubuntu.
3.6. Obtendo o teste no Ubuntu¶
O processo de envio de um autopkgtest para um pacote é muito semelhante a corrigindo um erro no Ubuntu. Essencialmente, você simplesmente:
execute bzr branch ubuntu:<nomedopacote>,
edite debian/control para habilitar os testes,
adiciona o diretório debian/tests,
escreva o debian/tests/control baseado no DEP 8 Specification,
adicione seu(s) caso(s) de teste em debian/tests,
submeta suas mudanças, envie elas para o Launchpad, proponha a mesclagem e obtenha revisões apenas como qualquer outra melhoria no pacote fonte.
3.7. O que você pode fazer¶
O time de Engenharia do Ubuntu montou a “lista de casos de teste necessários”_, onde pacotes que necessitam ser testados são colocados em diferentes categorias. Aqui você pode encontrar exemplos desses testes e atribuí-los a você.
Se você incorrer em quaisquer problemas, você também pode se inscrever no “#ubuntu-quality IRC channel”_ para entrar em contato com desenvolvedores que podem ajudá-lo.