- PVSM.RU - https://www.pvsm.ru -
Привет, я Алексей, full-stack разработчик платформы Vimbox. Когда я пришел в Skyeng, здесь решали, стоит ли тратить время на систему автотестов и попросили меня поделиться опытом с предыдущей работы. А такой опыт у меня был: к моменту ухода с предыдущего места мы написали на php и крутили больше 3 тысяч тестов. В итоге я сделал небольшую внутреннюю презентацию, рассказывающую о граблях, на которые успел наступить за несколько лет разработки этих автотестов, борьбы за их скорость, читабельность кода и общую эффективность. Презентация показалась коллегам полезной, поэтому я переложил ее в текст, чтобы оказаться полезным также и более широкой аудитории.
Для начала – термины, о которых пойдет речь в статье:
Приемочные тесты
Модульные тесты
Функциональные тесты – промежуточное решение.
На старой работе мы писали много функциональных тестов, и главным вызовом оказалась скорость срабатывания. Приходилось подолгу ждать результата, даже при локальном запуске на компьютере разработчика. Скорость была настолько низка, что не получалось применять подход «разработка через тестирование», поскольку он предполагает запуск автотестов по нескольку раз в час. Нашли узкое место – работу с базой данных. Как с этим бороться?
Мок в PhpUnit – динамически создаваемый объект, класс которого динамически наследуется от пародируемого класса. Можно настраивать, что будут возвращать методы мока, можно проверять, какие методы мока сколько раз с какими параметрами были вызваны
Главный плюс моков – они позволяют отрезать целые куски функциональности. Подменяя службу моком, мы избавляемся от необходимости думать, что там происходит, разрабатывать дополнительные сценарии и фикстуры, чтобы все корректно заработало. В итоге: меньше фикстур, а скорость срабатывания выше за счет того, что мы отрезали лишний код, выполняющий запросы к БД.
Неявный плюс моков в том, что они заставляют лучше организовывать зависимости. Когда пишешь код, зная, что на него надо будет написать тест, где что-то подменится моками, ты сразу задумываешься о зависимостях.
Минус: код теста слишком привязан к реализации. Мы должны в ходе теста создать мок-объект и подумать, какие должны быть у него вызваны методы.
Второй обнаруженный минус состоит в том, что тесты стали менее надежны. Они «не замечают» даже изменения интерфейса, не говоря уж о реализации. Т.е. мы где-то удаляли метод и спустя длительное время обнаруживали, что покрывающие его тесты по-прежнему работают как ни в чем не бывало, потому что видели его мок, а тот делал вид, что все хорошо.
Считаю опыт с моками неудачным в плане ускорения тестов.
Следующий вариант – СУБД SQLite [1], она умеет создавать БД в оперативной памяти. Пришлось написать транслятор PostgreSQL схeмы в SQLite, после каждой миграции генерировали новую SQLite схему. Тесты из этой схемы создавали пустую БД в оперативной памяти. Такой подход поднял скорость тестов на локальных машинах в два-четыре раза. Стало реально прогонять весь комплект тестов несколько раз в час.
Но были и минусы. Мы потеряли многие нативные возможности PostgreSQL (json, некоторые удобные агрегатные функции и прочее). Запросы пришлось писать так, чтобы они срабатывали и на PostgreSQL, и на SQLite.
Это решение было рабочим, но вызывало некоторую боль. В определенный момент мы узнали [2], что PostgreSQL можно оптимизировать для автотестов, что сокращает время срабатывания примерно в четыре раза. Для этого надо добавить несколько настроект в postgresql.conf:
fsync=off
synchronous_commit=off
full_page_writes=off
Это настройки надежности, они гарантируют, что если сервер умрет в середине транзакции, она корректно завершится, когда все снова заработает. Понятно, что на продакшне такие настройки делать нельзя, но на автотестах это было удобно.
Такая настройка применяется для всего кластера, затрагивает все БД, ее нельзя применить для какой-то одной базы. Если получается локализовать базы в отдельный кластер и отключить в нем fsync – это очень удобно.
new
Отдельно хочется упомянуть опасность оператора new
. Службы, созданные с его помощью, невозможно подменить моками и стабами. Вывод:
new
для создания объектов, которые по своей сути являются службами.new
.Автор: anzem
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/postgresql/325589
Ссылки в тексте:
[1] СУБД SQLite: https://www.sqlite.org/
[2] узнали: https://stackoverflow.com/questions/9407442/optimise-postgresql-for-fast-testing
[3] Источник: https://habr.com/ru/post/461901/?utm_campaign=461901&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.