3. autopkgtest: Автоматичне тестування пакунків¶
Специфікація DEP 8 визначає, як можна легко інтегрувати автоматичне тестування у Ваші пакунки. Для цього, необхідно:
додати файл
debian/tests/control, який визначає вимоги до тестового оточення,додати тести в
debian/tests.
3.1. Вимоги до тестового оточення¶
У файлі debian/tests/control Ви можете визначити вимоги до тестового оточення. Наприклад, якщо тести не проходять при збірці, або потрібні права root – Ви перераховуєте необхідні для тестів пакунки. У Специфікації DEP 8 Ви знайдете усі доступні опції.
Нижче ми розглянемо пакунок джерельного коду 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.
Хоч цей тест дуже маленький і простий, він перевіряє багато: що Ваш -dev пакунок має усі необхідні залежності, що Ваш пакунок встановлює робочі файли pkg-config, заголовкові файли і бібліотеки поміщуються у потрібне місце, або що компілювальник та компонувальник працюють. Це допомогає виявити критичні помилки на початковій стадії.
3.3. Виконання тесту¶
Не дивлячись на те, що скрипт тестування може бути запущений напряму, все ж рекомендується використовувати adt-run з пакунку autopkgtest для перевірки проходження тестів; у протилежному випадку, якщо тест покаже помилку у системі Ubuntu Continuous Integration (CI) – пакунок не пройде в Ubuntu. Заодне можна уникнути “засмічування” Вашої робочої станції тестовими пакунками та конфігураціями у випадку, якщо тест здійснює дещо більш серйозне у відношенні системи, ніж у прикладі вище.
У документації README.running-tests (онлайн-версія:) пояснюються усі доступні тестові оточення (schroot, LXC, QEMU, etc) й наводяться найпопулярніші способи запуску тестів через adt-run. Наприклад, з локальною збіркою бінарників, локально модифікованими тестами, тощо
Система безперервної інтеграції Ubuntu CI використовує емулятор QEMU й запускає тести з пакунків у архіві, з увімкненим прапорцем -proposed. Щоб вручну отримати те ж оточення, спочатку необхідно встановити наступні пакунки:
sudo apt-get install autopkgtest qemu-system qemu-utils
Тепер виконайте збірку тестового оточення, виконавши таке:
adt-buildvm-ubuntu-cloud -v
(Детальніше про вибір інших релізів, архітектур, цільових директорій, й про використання проксі – в manpage й у виводі опції --help). Ця команда виконає збірку, наприклад adt-trusty-amd64-cloud.img.
Тепер запустіть тести джерельного пакунку, наприклад libpng, у образі QEMU:
adt-run libpng --- qemu adt-trusty-amd64-cloud.img
Система Ubuntu CI запускає пакунки з увімкненим прапорцем -proposed; щоб увімкнути це, запустіть:
adt-run libpng -U --apt-pocket=proposed --- qemu adt-trusty-amd64-cloud.img
Man-сторінка adt-run містить багато цінної інформації з інших параметрів тестування.
3.4. Подальші приклади¶
Цей перелік не повний, але може допомогти Вам отримати уяву про те, як автоматичні тести реалізовані, й як вони використовуються в Ubuntu.
Для бібліотеки libxml2 , тести дуже схожі. Вони також запускають тестову збірку простого коду на C й виконують його.
Пакунок gtk+3.0 tests <gtk3_> також компілює/лінкує/запускає перевірку у тесті “build”. Також є додатковий тест “python3-gi”, який перевіряє що бібліотека GTK може бути використана під час тесту.
У пакунку ubiquity tests використовується набір тестів батьківського пакунку
Пакунок gvfs tests – дуже цікавий приклад: він тестує свій функціонал “на повну”, включаючи емулювання CD, Samba, DAV та інших компонентів.
3.5. Інфраструктура Ubuntu¶
Пакунки з увімкненим autopkgtest будуть тестуватися при вивантаженні, або якщо оновляться якісь залежності. Результат роботи автоматичний запуск тестів autopkgtest може бути переглянутий на сайті, й він регулярно оновлюється.
Debian також використовує adt-run для запуску тестів пакунку, але на цю мить – лише в оточенні schroot, тож результати можуть різнитися. Результати і логи можна подивитися за посиланням http://ci.debian.net. Будь ласка, також відправляйте виправлення для тестів або нові тести в Debian.
3.6. Додавання тесту в Ubuntu¶
Процес додавання й відправлення autopkgtest-тесту для пакунків дуже схожий на процес виправлення помилок в Ubuntu. Вистачить лише:
виконайте
bzr branch ubuntu:<ім’я_пакунку>,увімкніть тести в
debian/control,створіть директорію
debian/tests,створіть
debian/tests/control, основуючись на Специфікації DEP 8,додайте Ваші тести в
debian/tests,закомте Ваші зміни, відправте їх на Launchpad, запропонуйте merge й дочекайтеся його розгляду, – у точності як з будь-якими іншими покращеннями у джерельних пакунках.
3.7. Чи Ви можете допомогти¶
Команда Ubuntu Engineering зібрала перелік необхідних тестів, у якому пакунки, що потребують тестування, розподілені за категоріями. Там можна знайти приклади таких тестів й взяти їх на себе.
Якщо Ви зіштовхнетеся з проблемами, приєднуйтеся до IRC на каналу #ubuntu-quality IRC channel: розробники звичайно Вам допоможуть.