# 3. autopkgtest: Автоматическое тестирование пакетов

Документ DEP 8 specification определяет способ лёгкой интеграции автоматического тестирования в пакеты. Всё, что необходимо сделать для добавления теста к пакету, это:

- добавить следующую строчку к разделу Source в `debian/control`:

      XS-Testsuite: autopkgtest

- добавить файл `debian/tests/control`, который определяет требования к тестовому окружению,

- добавить тесты в `debian/tests`.

## 3.1. Требования к тестовому окружению

В файле `debian/tests/control` вы можете указать требования к тестовому окружению. Например, можно задать список необходимых для тестирования пакетов, указать, требуется ли восстановление окружения после тестов, и нужны ли привилегии `root`. Все доступные опции указаны в DEP 8 specification.

Сейчас мы рассмотрим пакет исходного кода `glib2.0`. В очень простом случае он будет выглядеть так:

    Tests: build
    Depends: libglib2.0-dev, build-essential

Это будет означать, что для теста `debian/tests/build` требуются пакеты `libglib2.0-dev` и `build-essential`.

Примечание

В поле `Depends` можно указать `@`, если вы хотите установки всех бинарных пакетов, собранных из рассматриваемого пакета исходного кода.

## 3.2. Настоящие тесты

Тест, соответствующий рассмотренному выше примеру, будет выглядеть так:

    #!/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"

Здесь небольшая программа на языке C копируется во временную директорию, затем компилируется с использованием системных библиотек (с использованием флагов и путей к библиотекам, определённых через `pkg-config`). Затем запускается скомпилированный файл, который запускает несколько основных функций glib.

Несмотря на то, что тест небольшой и очень простой, он тестирует некоторое количество основных компонентов системы. Это позволит заранее выявить критические ошибки, если они возникнут.

## 3.3. Выполнение теста

Тестовый скрипт может быть легко запущен сам по себе, но если вы хотите убедиться, что тестовое окружение правильно настроено, вы можете использовать для запуска скрипт `adt-run` из пакета `autopkgtest`. Самый простой способ — выполнение этой команды в дереве исходного кода:

    sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null

Минус данного подхода — то, что он позволяет запустить тесты на локальной машине, но не даёт никаких гарантий того, что он будет работать в минимальном окружении. Например, будет сложно убедиться, что правильно указаны все нужные зависимости. С lp:auto-package-testing, у нас есть более продвинутые средства тестирования. Они используют «чистую» виртуальную машину для запуска тестов. Чтобы воспользоваться этими средствами, сперва нужно установить необходимые зависимости:

    sudo apt-get install qemu-utils kvm eatmydata

Затем получите исходный код с 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

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.

## 3.4. Дальнейшие примеры

Этот список не полон, но может помочь вам получить представление о том, как автоматические тесты реализованы, и как они используются в Ubuntu.

- Тесты libxml2 tests очень похожи. Они также производят тестовую сборку небольшого куска C-кода и запускают его.

- Тесты gtk+3.0 tests также производят проверку компиляции/линковки/запуска в тесте «build». Есть также дополнительный тест «python3-gi», который проверяет, что библиотека GTK может быть использована через механизм интроспекции.

- В ubiquity tests, выполняются тесты, предоставленные разработчиками.

- Тесты gvfs tests тестируют различную функциональность gvfs и представляют интерес, так как эмулируют использование CD, Samba, DAV и других компонентов.

## 3.5. Инфраструктура 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.

Несмотря на то, что у Debian пока нет инфраструктуры автоматического тестирования, тесты следует отправлять в Debian, так как DEP-8 — спецификация Debian, и разработчики и пользователи Debian могут запускать тесты вручную.

Пакеты Debian с заголовком `XS-Testsuite`, скопированные в Ubuntu, также будут добавлены в список тестируемых пакетов.

## 3.6. Добавление теста в Ubuntu

Процесс добавления и отправки autopkgtest-теста для пакета похож на процесс исправления ошибки в Ubuntu. Необходимо просто:

- выполните `bzr branch ubuntu:<имя_пакета>`,

- включите тесты в `debian/control`,

- создайте директорию `debian/tests`,

- создайте `debian/tests/control`, следуя требованиям DEP 8 Specification,

- добавьте ваши тесты в `debian/tests`,

- закрепить ваши изменения, отправить их на Launchpad, создать заявку на слияние (merge proposal) и дождаться, пока она будет рассмотрена (как и любое другое изменение пакета).

## 3.7. Чем вы можете помочь

Команда инженеров Ubuntu создала список необходимых тестов (list of required test-cases), где пакеты, которым требуются тесты, разбиты на различные категории. Там вы можете посмотреть на примеры таких тестов и сами заняться каким-то из них.

Если у вас возникнут какие-то проблемы, зайдите на #ubuntu-quality IRC channel, на котором есть готовые помочь вам разработчики.