Привет, я Алексей, full-stack разработчик платформы Vimbox. Когда я пришел в Skyeng, здесь решали, стоит ли тратить время на систему автотестов и попросили меня поделиться опытом с предыдущей работы. А такой опыт у меня был: к моменту ухода с предыдущего места мы написали на php и крутили больше 3 тысяч тестов. В итоге я сделал небольшую внутреннюю презентацию, рассказывающую о граблях, на которые успел наступить за несколько лет разработки этих автотестов, борьбы за их скорость, читабельность кода и общую эффективность. Презентация показалась коллегам полезной, поэтому я переложил ее в текст, чтобы оказаться полезным также и более широкой аудитории.


Для начала – термины, о которых пойдет речь в статье:


  • Приемочный тест – end-to-end тест: здесь браузер или эмулятор браузера исполняет сценарий
  • Модульный тест (юнит тест) – тест метода
  • Функциональный тест – тест контроллера или компонента, если речь о фронтенде
  • Фикстура – состояние тестового окружения, необходимое для работы теста (глобальные переменные, данные в БД и прочие участники сценария теста)

Плюсы и минусы разных видов тестов



Приемочные тесты


  • Плюсы: очевидны из названия, такие тесты покрывают всю систему сверху донизу, позволяют убедиться, что все работает как следует.
  • Минусы: обратная связь от этих тестов очень медленная, они долго срабатывают, они не очень надежны, много ложных срабатываний. На прошлой работе также столкнулись с тем, что веб-драйвера не обнаруживали некоторые элементы, которые мы видели глазами. Сейчас это, наверное, исправлено, а тогда пришлось от них отказаться.

Модульные тесты


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

Функциональные тесты – промежуточное решение.


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

Борьба за скорость


На старой работе мы писали много функциональных тестов, и главным вызовом оказалась скорость срабатывания. Приходилось подолгу ждать результата, даже при локальном запуске на компьютере разработчика. Скорость была настолько низка, что не получалось применять подход «разработка через тестирование», поскольку он предполагает запуск автотестов по нескольку раз в час. Нашли узкое место – работу с базой данных. Как с этим бороться?


Опыт перый: моки


Мок в PhpUnit – динамически создаваемый объект, класс которого динамически наследуется от пародируемого класса. Можно настраивать, что будут возвращать методы мока, можно проверять, какие методы мока сколько раз с какими параметрами были вызваны


Главный плюс моков – они позволяют отрезать целые куски функциональности. Подменяя службу моком, мы избавляемся от необходимости думать, что там происходит, разрабатывать дополнительные сценарии и фикстуры, чтобы все корректно заработало. В итоге: меньше фикстур, а скорость срабатывания выше за счет того, что мы отрезали лишний код, выполняющий запросы к БД.


Неявный плюс моков в том, что они заставляют лучше организовывать зависимости. Когда пишешь код, зная, что на него надо будет написать тест, где что-то подменится моками, ты сразу задумываешься о зависимостях.


Минус: код теста слишком привязан к реализации. Мы должны в ходе теста создать мок-объект и подумать, какие должны быть у него вызваны методы.


Второй обнаруженный минус состоит в том, что тесты стали менее надежны. Они «не замечают» даже изменения интерфейса, не говоря уж о реализации. Т.е. мы где-то удаляли метод и спустя длительное время обнаруживали, что покрывающие его тесты по-прежнему работают как ни в чем не бывало, потому что видели его мок, а тот делал вид, что все хорошо.


Считаю опыт с моками неудачным в плане ускорения тестов.


Опыт второй: SQLite


Следующий вариант – СУБД SQLite, она умеет создавать БД в оперативной памяти. Пришлось написать транслятор PostgreSQL схeмы в SQLite, после каждой миграции генерировали новую SQLite схему. Тесты из этой схемы создавали пустую БД в оперативной памяти. Такой подход поднял скорость тестов на локальных машинах в два-четыре раза. Стало реально прогонять весь комплект тестов несколько раз в час.


Но были и минусы. Мы потеряли многие нативные возможности PostgreSQL (json, некоторые удобные агрегатные функции и прочее). Запросы пришлось писать так, чтобы они срабатывали и на PostgreSQL, и на SQLite.


Опыт третий: оптимизация PostgreSQL


Это решение было рабочим, но вызывало некоторую боль. В определенный момент мы узнали, что PostgreSQL можно оптимизировать для автотестов, что сокращает время срабатывания примерно в четыре раза. Для этого надо добавить несколько настроект в postgresql.conf:


fsync=off
synchronous_commit=off
full_page_writes=off

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


Такая настройка применяется для всего кластера, затрагивает все БД, ее нельзя применить для какой-то одной базы. Если получается локализовать базы в отдельный кластер и отключить в нем fsync – это очень удобно.


Немного о new


Отдельно хочется упомянуть опасность оператора new. Службы, созданные с его помощью, невозможно подменить моками и стабами. Вывод:


  • Не использовать new для создания объектов, которые по своей сути являются службами.
  • Можно использовать в фабриках, потому что их можно будет подменить. Но сами фабрики не должны создаваться через new.
  • Можно использовать для создания моделей, сущностей, DTO (data transfer object), value-objects.

Выводы из трехлетнего опыта


  • На прошлой работе мы отказались от приемочных тестов, но сейчас я бы их снова попробовал: скорее всего в веб-драйверах пофиксили многие баги.
  • Если нужно покрыть новый функционал тестами, надо писать только функциональные тесты контроллеров/компонентов. В этой ситуации у нас высок риск структурных изменений, модульные тесты к ним неустойчивы.
  • Таких тестов не должно быть много, потому что много == медленно, они срабатывают не так быстро, как модульные. Покрывать стоит только те случаи, которые могут «выстрелить» (имеют вероятность ошибки в будущем).
  • Модульные тесты пишутся на алгоритмически-насыщенные методы (сложная логика, которую надо тестить) или на методы с небольшим риском структурных изменений в будущем.
  • Минусы моков в целом превышают плюсы. Имеет смысл использовать их только как подмену шлюзов во внешние API, ну и иногда служб из легаси-кода, которые очень трудно протестировать.
  • Если решили писать код без теста, желательно при его создании думать «а что, если в будущем мы все-таки захотим написать на это тест?»
  • Тесты должно быть писать легко и приятно, они придают надежности, уверенности, помогают лучше понимать код, управлять зависимостям.
  • Обращаем внимание на читабельность тестов. Надо относиться к коду теста так же, как и к коду, который он покрывает.
  • Фикстуры БД – часть теста, тоже должны быть читабельными

Комментарии (11)


  1. ghrb
    31.07.2019 13:26
    +1

    fsync=off
    synchronous_commit=off
    full_page_writes=off


    У меня в проекте в четыре раза время не сократило, но почти в два раза стало меньше. Что тоже хорошо.


    1. amakhrov
      31.07.2019 14:42

      Для MySQL я использовал


      innodb_flush_log_at_trx_commit = 0

      Тоже заметно сокращало время работы тестов. Может, кому пригодится.


  1. SEVNTEC
    31.07.2019 15:39

    А чем тестируется UI, Selenium?


    1. anzem Автор
      31.07.2019 15:43
      +1

      UI пытались тестировать с помощью phantomjs и headless chrome, тогда использовали Codeception framework для этого. Для ангуляра — Protractor. Но в итоге отказались от UI тестов из-за частых false positive срабатываний и очень низкой скорости.


  1. alexkrash
    31.07.2019 19:44
    +1

    Мы у себя такую используем самопал — DbMocks, подробности тут:
    habr.com/ru/company/badoo/blog/443768
    Если у вас у таблицы foreign key и триггеры, то это несколько сложнее, но раз уж вы научились это транслировать в SQLite, то наверное и свой DbMocks сделаете :)


  1. C4ET4uK
    31.07.2019 21:15

    Я если честно не силен в php, но насколько я понял автор называет главной проблемой моков —

    Второй обнаруженный минус состоит в том, что тесты стали менее надежны. Они «не замечают» даже изменения интерфейса, не говоря уж о реализации.

    В языках со статической типизацией мок наследуется от интерфейс и если вдруг что-то пропало — просто не скомпилируется. То есть это проблема не моков, а PHP?


    1. ApeCoder
      01.08.2019 09:15

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


      https://habr.com/ru/post/150859/


  1. anzem Автор
    01.08.2019 06:43
    +1

    C4ET4uK Верно подмечено, если бы 1) мы писали на статически-типизированном языке и 2) добавили бы небольшой оверхед в виде интерфейсов на каждый класс, на который нужен мок, то да, эта проблема бы ушла. И всё же, это не главная проблема. Для нас очень важен подход разработки через тестирование, которые меняет мышление — заставляет отвлечься от деталей реализации и подумать о конечном результате. Моки ломают этот настрой — заставляли задумываться о реализации. Это серьёзный недостаток.


  1. BogdanH
    01.08.2019 15:54
    +2

    У нас на проекте около 4000 тестов, поведенческие, функциональные, модульные. Могу сказать из своего опыта, что более всего важны функциоальные тесты, практика черного ящика, не важно как система организована внутри, главное чтобы при передачи данных она вернула ожидаемый ответ. И да, никогда, никогда не используйте SQLite :D Система должна тестироваться с базой с которой она работает в лайве, рано или поздно вы словите неприятную ошибку, что тест падает, а функицонал работает, потом окажется, что SQLite не поддерживает что-то из MySQL или PostgreSQL.


  1. anzem Автор
    01.08.2019 15:59

    BogdanH Согласен, мы, кстати, тоже пришли к выводу, что функциональные тесты наиболее полезны при разработке


  1. OperatorPEVM
    02.08.2019 05:32
    +1

    На прошлой работе также столкнулись с тем, что веб-драйвера не обнаруживали некоторые элементы, которые мы видели глазами. Сейчас это, наверное, исправлено, а тогда пришлось от них отказаться.

    По поводу этой пролемы- в самом селениуме это не исправлено до сих пор. Но нашлись умные ребята, которые написали надстройку на Java, называется Selenide. Она эту проблему решает. Лично использовал ее порты под питон (Selene) и .NET. — NSelene. Работает отлично, да и куда она денется, собственно настройка заточена под решение данной проблемы.