Skip to content

Latest commit

 

History

History
216 lines (142 loc) · 11 KB

2.2-testing-badoo.md

File metadata and controls

216 lines (142 loc) · 11 KB

docops

Монолит для сотен версий клиентов: как мы пишем и поддерживаем тесты

Владимир Янц, Badoo

Содержание

Темы:

  1. Наш процесс разработки
  2. Юнит-тесты
  3. Интеграционные тесты
  4. Тесты на API
  5. Прогон тестов

Процесс разработки

К сроку выкатывания фичи добавляется:

  • desktop web + два месяца
  • mobile web + неделя
  • iOS + месяц
  • android + полгода

Разработчик отвечает за фичу от бэкенда до реализации на платформах. Интеграция бывает нескоро. Поэтому хочется сделать так, чтобы интеграция прошла хорошо.

Нужны автотесты!

Unit-tests

Тесты на изолированные кусочки кода.

Сложно тестировать легаси. Для него делаем SoftMocks. Оно перехватывает все include/require в PHP-файле, подменяет подключаемый файл на другой.

Можно мокать любые методы: статические, приватные, финальные.

Проблема: SoftMocks расслабляют — можно писать плохо тестируемый код и всё равно покрыть его тестами. Решили правилами:

  • новый код должен быть легко тестируемым с помощью PHPUnit
  • SoftMocks — крайний случай, когда иначе нельзя.

Правила проверяются на код-ревью.

Мутационное тестирование.

  1. берем код

  2. берем code coverage

  3. парсим код и генерируем мутации: меняем плюс на минус, true на false

  4. для каждой мутации прогоняем набор тестов:

    • если тесты упали — они хорошие
    • если тесты успешно прошли — они недостаточно эффективны

Для PHP есть готовые решения: Humbug, Infection. Но они несовместимы с SoftMocks. Поэтому написали своё.

Интеграционные тесты

Тестируем работу нескольких компонентов в связке.

Стандартный подход:

  1. Поднимаем тестовую БД
  2. Заполняем её
  3. Запускаем тест
  4. Очищаем БД

Есть проблемы:

  • нужно поддерживать актуальность содержимого базы
  • требуется время на подготовку
  • параллельные запуски делают тесты нестабильными и порождают дедлоки (когда тесты работают с одной и той же таблицей)

Решение: DBMocks

  1. Методы драйверов DB перехыватываются с помощью SoftMOcks на setUp теста
  2. из запроса вытаскиваются db + table
  3. создаются временные таблицы с такой же схемой
  4. все запросы идут во временные таблицы
  5. потом на tearDown они удаляются

Результаты:

  • тесты не могут повредить данные в оригинальных таблицах
  • тестируем совместимость запроса с версией MySQL.
  • тесты вообще ходят в ту же БД по тому же адресу (просто таблица другая)
  • тесты изолированы друг от друга

API-тесты

  • имитируют клиентскую сессию
  • умеют слать запросы к бэкенду
  • бэкенд отвечает почти как реальному клиенту

Обычно такие тесты требуют авторизованного пользователя. Его нужно создать перед тестом и удалить после. Это порождает риск нестабильности, потому что при создании пользователя есть репликация и фоновые задачи.

Решение: пул тестовых пользователей.

  1. Нужен пользователь
  2. ищем в пуле
  3. если нет — создаём
  4. после теста очищаем, потому что тест загрязняет пользователя

Тестовые пользователи в одном окружении с реальными? Зачем вообще их тестировать на бою? Потому что devel ≠ prod. Надо изолировать, иначе пользователи будут флиртовать с кучей фиктивных Олегов.

Путь 1: флаг is_test_user, по флагу изолируем внутри сервисов.

Путь 2: всех пользователей переселяем в условную Антарктиду и они там тусят друг с другом.

QA API

бэкдор для тестирования

  • хорошо документированные методы API
  • быстро и легко управляют данными
  • пишут их бэкенд-разработчики
  • применимы только к тестовым пользователям

Позволяют сменить пользователю неизменяемые данные, вроде даты регистрации.

Безопасность

  • сетевая изоляция — доступно только из офисной сети
  • с каждым запросом передаётся secret, валидность которого проверяем
  • методы не работают с реальными пользователями
  • программа BugsBounty на hackerone

Прогон тестов

  • 100 000 юнит, 40 минут
  • 6 000 интеграционных, 90 минут
  • 14 000 API, 600 минут

Распараллелили тесты в TestCloud.

Как распределить тесты между потоками?

  • поровну — фигня, все тесты разные, получатся неравные по времени части
  • запустить несколько потоков и скармливать тесты по одному — тратим время на инициализацию PHP-окружения. Долго!

Как сделали:

  • собираем статистику по времени прогона
  • компонуем тесты так, чтобы один chunk прогонялся не более чем за 30 секунд

Проблема: медленные тесты занимают ресурсы, не давая выполняться быстрым. Т.е. API могут занять весь Cloud.

Решение: разделили Cloud

  • часть 1 прогоняет только быстрые тесты
  • часть 2 прогоняет любые тесты

Результат:

  • Unit — 1 минута
  • Интеграционные — 5 минут
  • API — 15 минут

Какие тесты выполнять? Покажет code coverage.

  1. Получаем branch diff
  2. формируем список измененных файлов
  3. получаем список тестов, которые его покрывают
  4. запускаем прогон набора только из этих тестов

А где взять coverage?

  • раз в сутки, ночь, полный прогон с test coverage
  • результаты складываем в БД

Плюсы:

  • прогоняем меньше тестов: меньше нагрузка на железо и быстрее обратная связь
  • можем запускать тесты для патчей. Это позволяет быстро выкатить хотфикс. В патчах скорость важнее всего.

Минусы:

  • Релизим бэкенд дважды в день, так что coverage актуален только для первого. Поэтому для билда прогоняем полный набор тестов.
  • API-тесты генерируют слишком большой coverage. Для них этот подход не даёт большой экономии.

Итоги

  • все уровни пирамиды тестирования нужны и важны
  • количество тестов ≠ качество. Делайте ревью кода тестов и мутационное тестирование.
  • изолируйте тестовых пользователей от реальных.
  • бэкдоры в бэкенде упрощают и ускоряют разработку тестов.
  • собирайте статистику по тестам.

Ссылки