[devel] про автоматическое и ручное тестирование пакетов

[Evgeny Sinelnikov]

16 июня 2009 г. 2:33 пользователь Dmitry V. Levin (ldv at altlinux.org) написал:
> On Sun, Jun 14, 2009 at 03:51:18PM +0300, Kirill A. Shutemov wrote:
>> 2009/6/14 Kirill Maslinsky <kirill at altlinux.org>:
> [...]
>> > Формализованные тесты на функциональность, включённые в пакет мантейнером,
>> > выполняемые после успешной сборки пакета в безопасном окружении,
>> > гаранитрующие отсутствие регрессий по данной функциональности
>> > при пересборке в любом окружении.
>>
>> Ядро и всё околожелезное так не протестируешь в принципе. Многое из оставшегося
>> протестировать в автоматическом режиме тоже малореально.
>
> Если ставить перед собой цель увеличивать покрытие автоматическими
> тестами, и работать в этом направлении, то можно получить положительный
> результат, недостижимый при тестировании вручную.  Это два ортогональных
> подхода, которые в принципе можно развивать независимо друг от друга.
>
> Например, https://bugzilla.altlinux.org/show_bug.cgi?id=20463 не возникло
> бы, если бы на момент сборки пакета было реализовано соответствующее
> автоматическое тестирование.  Собственно говоря, я рассчитывал, что
> тестирование принимаемых в Сизиф пакетов пересборкой зависящих от них
> пакетов будет введено в строй ещё до окончания весны, но один не очень
> хороший человек (по запросу я готов назвать его имя) нарушил
> договорённость об использовании оборудования для этой цели.
>
> Я на данный момент не вижу, в чём заключается значимое преимущество
> централизованных "карманов" для предварительного тестирования, о которых
> так много говорят последнее время, над распределёнными "карманами", которые
> каждый может устроить где угодно при наличии соответствующих ресурсов.
> Могу лишь предположить:
> - информация (централизованный "карман" немного легче обнаружить);
> - доступность (централизованная сборка в среднем более доступна всем
>  заинтересованным);
> - интеграция (централизованный "карман" теоретически должно быть немного
>  легче интегрировать в "материнский" репозиторий);
> На данный момент мне эти преимущества не кажутся значимыми.
> Грубо говоря, я не вижу, каким образом появления централизованных
> "карманов" заметно повысит качество предварительного ручного тестирования.
>
> Есть другие соображения на эту тему?
>

Да, кроме того, что уже было сказано о самодостаточной ценности
"упрощения работы разработчиков Сизифа", с которой я, в принципе
согласен, я хочу привести ещё ряд аргументов:
- распределённая модель разработки (Я уже приводил свою аналогию с
Git) - такая модель должна снизить издержки на предварительное
тестирование, которым, при текущей модели, вынуждены заниматься все
вместе. При этом взаимовлияние ошибок сейчас является трудно
отслеживаемым. Кроме того, текущая модель, не даёт возможности делать
"мягкие" bootstrap'ы. Сейчас это всегда волевое решение.
- средство для оценки и самооценки результатов сборок новичков. Дело в
том, что ни один новичок с ходу, скорее всего, не придумает куда ему
выкладывать свои предварительные наработки. Таким образом он вынужден
долго топтаться на месте, вместо того чтобы получить грамотную оценку
своих результатов у коллег из Team.
- возможность конкуренции и параллельных сборок в команде не
приводящая к конфликтам, а позволяющая вести технические споры на
техническом поле. Например, все вопросы по сборке samba4, а теперь уже
есть резон собирать её совместно с samba3, я мог бы выполнить в таком
отдельном Дедалусе под задачу. Последнее здесь мне кажется наиболее
важным. Исходный Дедалус был свалкой, мне бы не хотелось смешивать
сборочные среды своих отдельных задач.

И да... всё это можно делать отдельно на своей какой-то базе... Но от
этого, мне кажется пропадает какое-то единство при работе в команде...
Я ведь могу попытаться сделать описанное и на git.etersoft.ru. Но вы
ведь сами понимаете, что это будет маргинальный ресурс.

-- 
Sin (Sinelnikov Evgeny)