Тесты визуальной регрессии. Перезагрузка

21 декабря 2019 в 14:00

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

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

Оптимизация быстродействия

Начали, как ни странно, с оптимизации быстродействия. Объясню, почему. Наши визуальные тесты базируются на Storybook. Каждая story в storybook — это не отдельно взятая компонента, а целый «блок» (например, грид со списком сущностей, карточка сущности, диалог или даже приложение в целом). Чтобы отобразить этот блок, необходимо «накачать» story данными, причем не только данными, отображаемыми пользователю, но и состоянием компонент, используемых внутри блока. Эта информация хранятся вместе с исходным кодом в виде json-файлов, содержащих сериализованное представление состояния приложения (redux store). Да, эти данные, мягко говоря, избыточны, но зато сильно упрощают создание тестов. Чтобы создать новый тест, мы просто открываем в приложении нужную карточку, список или диалог, делаем снимок текущего состояния приложения и сериализуем его в файл. Затем добавляем новую story и тесты, которые делают скриншоты этой story (все это в несколько строк кода).

Такой подход неизбежно увеличивает размер бандла. Степень дублирования данных в нем просто «зашкаливает». При прогоне тестов движок gemini выполняет каждый тестовый набор (test suite) в отдельной сессии браузера. Каждая сессия грузит бандл заново и размер бандла в такой схеме имеет далеко не последнее значение.

Чтобы уменьшить время прогона тестов, мы уменьшили количество test-suite, увеличив количество тестов в них. Таким образом, один test suite мог затрагивать сразу несколько story. В такой схеме мы практически потеряли возможность «скринить» только определенную область экрана из-за того, что Gemini позволяет задавать область скриншота только для test suite в целом (хотя API и позволяет делать это перед каждым скриншотом, но на практике это не работает).

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

Продолжение на Хабр.

DIRECTUM | Как сделать из не тенантного приложения мультитенантное

Как сделать из не тенантного приложения мультитенантное

14 января в 15:30

Почему приложение в облаке должно быть мультитенантным? А почему его сразу не делают мультитенантным? 
На примере микросервисной системы DirectumRX предложили реализацию мультитенантности в приложении, которое спроектировано как не тенантное.

Читать
DIRECTUM | Cерия технических митапов Directum

Cерия технических митапов Directum

19 декабря 2019 в 14:00

Завершили год серией технических митапов Directum. С октября по декабрь провели 3 митапа c годным контентом от экспертов компании.

Читать