# 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 Trusty AMD64 system:

    ./bin/prepare-testbed -r trusty amd64

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

    ./bin/run-adt-test -r trusty -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.