Тестирование
Главная идея
Все функциональные тесты создаются в виде DirAAP.
Распространяются и обновляются, как git или как app соответствующей платформы.
Тесты ставятся рядом с рабочим продуктом.
Желательно, ставиться и обновляться той же схемой, что и основной продукт.
Колво объектов в тестовой БД должно быть в 10 раз больше от реальных условий.
Обязательно проводим тесты ускоренного или сдвигаемого времени, для отлова ошибок перехода через 00 часов или 1 число месяца или 1 ое число года.
Тестовые виртуалки есть у каждого разработчика.
Есть тестовая вирталка для тестировании ветки testing где есть все коммиты всех разработчиков.
TODO причесать.
- тесты делятся на группы тестов (test_se_auto, test_api, test_cabinet и прочие)
- тесты деляется на быстрые (fast) и медленные (slow); рекомендуется соответствующие тесты располагать в подкаталогах <группа_тестов>/fast/ и <группа_тестов>/slow/
- придерживаемся directory as service, максимально все, необходимое для работы теста, должно располагаться внутри каталога с группой тестов; ислючения: устанавливаемые приложения (jenkins, firefox, selenium) - ставятся прямо в систему и конфигурируются скриптами, возможно использование общих библиотек для разных групп тестов
- в каждоый группе тестов в корне должно быть 2 файла: slow_test.sh и fast_test.sh, которыми запускается группа тестов; должны быть bash-скриптами, по-умолчанию содержат 1 строку с запуском внутреннего фреймворка/обходчика тестов данной группы тестов
Правила тестов:
- если тесту нужно запустить скрипт изнутри чрута (например, asr_billing), то он копирует нужный скрипт внутрь перед запуском и запускает
- для быстрых тестов действует ограничение: максимум 1 минута на выполнение для одной группы тестов; чтобы 1 прогон занимал минут 5-10, а разработчик попил чай/проверил почту, но сильно не отвлекся
Апп:
- тесты поставляются в аппе /app/tests_$PROFILE
- собирается и ставится с makedistro и или updater
- является directory-app и одновременно чрутом(для селениум файрфокс и тп)
- конфигурируются в /app/test_CRB-Billing/cfg/config
- запускаются /app/test_CRB-Billing/service fast_test и /app/test/service slow_test
- в аппе содержатся тесты для всех продуктов, располагаются:
/app/test_CRB-Billing/test_group1/fast/
/app/test_CRB-Billing/test_group2/fast/
/app/test_CRB-Reductor/test_group1/fast/
/app/test_CRB-Reductor/test_group1/slow/
/app/test_CRB-Reductor/test_group2/fast/
- если для аппа нужно будет устанавливать приложения (jenkins, selenium), скрипт запуска тестов должен будет это делать сам, makedistro в апп приложения не устанавливает, в аппе только скрипты запуска тестов и сами тесты
- весь енвайромент должен поставляться в чруте в готовом виде, на хост ничего не ставим
Главный обходчик:
- запускается из крона и или руками
- конфигурируется через config
- для запуска тестовых групп использует jenkins (как сделано в makedistro)
- несет ответственность за блокировку/разблокирочку обновления
Тестовая сборка, бранч test:
- в него мержатся все бранчи разработчиков
- на него настроена виртуалка с тестированием
/app/tests_CRB-Reductor/service /app/tests_CRB-Reductor/src.list /app/tests_CRB-Reductor/tests_reductor/.git /app/tests_CRB-Reductor/tests_reductor/fast_test /app/tests_CRB-Reductor/tests_reductor/fast/ /app/tests_CRB-Reductor/tests_reductor/slow_test /app/tests_CRB-Reductor/tests_reductor/slow/ /app/tests_CRB-Reductor/tests_reductor_satellite/.git /app/tests_CRB-Reductor/tests_reductor_satellite/slow_test /app/tests_CRB-Reductor/tests_reductor_satellite/slow/ /app/tests_CRB-Reductor/tests_bgp_blackhole/.git /app/tests_CRB-Reductor/tests_bgp_blackhole/fast/ /app/tests_CRB-Reductor/tests_bgp_blackhole/fast_test /app/tests_CRB-Reductor/tests_bgp_blackhole/slow/ /app/tests_CRB-Reductor/tests_bgp_blackhole/slow_test
Дополнение1
/app/tests_crb-billing5 тоесть имя профиля /app/tests_$PROFILE
внутри есть полный енвайромент-чрут для запуска firefox selenium и тд
тесты в виде каталогов с .git подкаталогом чтоб можно было сразу разрабатывать и править
/app/tests_crb-billing5 является и чрутом и не чрутом, чтоб можно было от корня запускать
Отдельный профайл tests_crb-billing5, в идеале он имеет туже версию что и продукт, и лежит в апдейтерАХ на мейкдитрах(в будущем на update5) как продукт, и ставится с апдейтера тулзой можно в стиле rsync.
Обсуждение
Я бы добавил уточнение про поставку утилит тестирования в продукт. Например, юнит-тесты, для простоты, могут поставляться вместе с кодом, но спец. утилиты (например, для сдвига времени, для проведения тестов) - должны поставляться в комплекте тестирующего сервиса и доустанавливаться им. Создание особой тестовой сборки я считаю нерациональным, т.к. по pl7 мы поставляем приложения с максимальнымы возможностями отладки на месте и нужды в пересборке/перекомпиляции быть не должно.
Связано это с локальностью тестирующих скриптов и технологий тестирования, а также с отключением возможности запустить деструктивный скрипт на продакшене по ошибке.
добавил дополнение и todo по резалтам нового совещания
Поддержу Николая. Основной код тестов, который может работать внутри продукта, имеет смысл внутри продукта и держать. Снаружи только системные вещи, которые на ОС влияют.
Я немного неправильно выразился. Говоря про юнит-тесты, я имело в виду код, который можно выполнить при сборке а-ля make build test install. А вот итеграционные тесты, либо тесты которые завязаны на окружение (а также скрипты настройки этого окружения) - я бы предпочел держать и распространять отдельно от основного продукта (в тестовом аппе).
(jenkins, firefox, selenium) в итоге в чуруте или нет?
Да, в чруте
Тогда они не смогу запускать тесты находящиеся в окружении контейнера, например биллинга
Можно тестам обеспечить доступ к app через ssh 169.254.хх.хх Но ключи для авторизации должен какой-то хук прописывать из корня. Тогда тесты даже не обязательно будет на той-же ВМ держать.
Предполагается, что тесты запускаются от корня.
А если надо протестировать вебку то test.sh запустит chroot $test selenium+firefox, а firefox'у не нужен доступ к другим чрутам.
Подробнее работа идет здесь https://wika.carbonsoft.ru/проект_reductor:документация_проекта:тестирование:autotests-and-ci
TODO перенести сюда обсуждение?
Но если это делает jenkins и он в chroot, то как он запустить тесты от корня? Хотя для биллинга это уже не актуально т.к. выяснилось что запуск тестов из jenkins на самой виртуалки каким то образом замедляет время выполнения аж в 8 раз, разбираться в чем дело было не рентабельно т.к. за пару часов не разобрались и решено было перенести запуск тестов на makedistro который эту ветку собирает, так что как будет свободное время соберу апп где будут все тесты и необходимое окружение
предполагается, что это делает bash обходчик, а не дженкинс.
если баш обходчик в одной из групп тестов должен запустить корневой jenkins, то нужно сделать чтоб такой дженкинс работал как dirapp без чрута(или хотябы скрипт по его установке).
прочитал
Вынесли тесты в chroot, только поскольку тестируем питоном то поставляются они в виде python пакетов с соответствующим путем, запускаем их из makedistro т.к. перед тестированием надо запустить обновление и оно убьет апп в котором мы обновление запустим, если это делать из chroot, плюс jenkins/java жрет много ресурсов.
если честно я не понял, возможно стоит показать визуально или на совещании