Что действительно требует UI-тестирования
Сценарий работает от начала до конца. Пользователь может пройти путь от намерения до результата. Ни один уровень ниже интерфейса не даст на это ответа.
Состояние между шагами. То, что задано на одном экране, учитывается на следующем. Именно здесь скапливаются настоящие дефекты.
То, что сказано пользователю, соответствует тому, что произошло на самом деле. Сообщение об успехе, за которым не стоит сохранённая запись, — самая частая ложь приложения.
Чему не место в UI-тесте
Правила валидации
Прогонять через браузер все комбинации некорректного ввода медленно и хрупко.
Проверьте одну в UI, остальные — на уровне API.
Вычисления
Модульный тест отвечает на это за миллисекунды и с более внятным сообщением об ошибке.
Подготовка данных
Прокликивать пять экранов ради создания тестовых данных медленно, и это ломается по причинам, не связанным с тем, что вы проверяете.
Размер набора
Два полезных правила. Покрывайте сценарии не по важности, а по тому, насколько незаметно они сломаются: за важными сценариями следят, за тихими — нет. И перестаньте добавлять тесты, когда стоимость поддержки начинает съедать сэкономленное время, — этот момент наступает раньше, чем ожидает большинство команд.
Три привычки
Устойчивые якоря, а не CSS-пути. Снимает большую часть поломок при редизайне.
Ждите состояния, а не времени. Снимает большую часть нестабильности.
Проверяйте то, что подтвердится после перезагрузки страницы. Снимает ложную уверенность, которую даёт сообщение об успехе.
Как перенести тест уровнем ниже на практике
С советом переносить проверки ниже интерфейса легко согласиться, но непонятно, как ему следовать, — поэтому вот как это выглядит на конкретном примере.
У вас есть браузерный тест, который заполняет форму регистрации четырнадцатью разными некорректными значениями и каждый раз проверяет сообщение об ошибке. Он идёт четыре минуты, ломается при любом изменении вёрстки формы и почти ничего не говорит вам о браузере.
Замените его одним браузерным тестом, который отправляет одно некорректное значение и подтверждает, что пользователю показана ошибка, и тринадцатью API-тестами, которые проверяют правила валидации напрямую. Теперь браузерный тест отвечает на браузерный вопрос, правила покрыты быстрее и точнее, а изменение валидации больше не требует трогать то, что отрисовывается.
То, что дисциплиной не исправить
Селекторы
Редизайн, который ничего не меняет функционально, окрашивает весь набор в красный.
Именно сюда уходит большая часть времени на поддержку.
Ожидания
Фиксированные задержки медленные и всё равно нестабильные. Правильному ожиданию нужно знать, чего именно ждать.
Большая часть нестабильности тянется отсюда.
Покрытие, написанное вручную
Вы покрываете то, что кто-то написал, — то есть интересные сценарии, а не те, которые ломаются.
Третий пункт — структурный. Покрытие, ограниченное временем автора тестов, будет отставать от продукта, код которого всё чаще приходит от агента. С этой частью работают шаги, описанные через намерение, и генерируемое покрытие.
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Тот же набор возможностей доступен в дашборде для тех, кто не хочет ставить ничего локально, а полный перечень команд — в репозитории CLI.
Подключите репозиторий из дашборда — и запуски будут стартовать с того деплоя, который вы и так собираете, либо вместо этого добавьте отдельный шаг в свой рабочий процесс.
Что TestSprite покрывает на каждом уровне
Сценарии в браузере — там, где ответ может дать только браузер, — и лежащий ниже уровень API в том же проекте. Именно это делает совет «переноси ниже» практичным, а не благим пожеланием: правила валидации переезжают в API-кейсы, которые выполняются за секунды, а один браузерный кейс проверяет, что форма к ним подключена.
И то и другое генерируется на основе вашего продукта и уточняется обычным языком, а шаги в браузере описаны через намерение, а не через селекторы, поэтому набор переживает редизайны, которые ничего не меняют функционально.
В итоге вы получаете браузерный набор, достаточно небольшой, чтобы ему доверяли, покрывающий действительно важные пути пользователя, — а правила и граничные случаи покрыты быстрее уровнем ниже.
Сколько UI-тестов нужно?
Столько, чтобы покрыть пути, сломать которые было бы стыдно, — и выбирать их по тому, насколько незаметно они откажут. Всё остальное переносите уровнем ниже.
Нужно ли тестировать каждый экран?
Нет. Тестируйте сценарии, а не экраны. Экран, через который не проходит ни один сценарий, редко оправдывает браузерный тест.
А как быть с доступностью?
Механические проверки автоматизировать стоит, для остального нужен просмотр человеком. Это отдельная задача со своим инструментарием.
Нужно ли покрытие в разных браузерах?
Зависит от вашей аналитики. Многие команды прогоняют полный набор в одном браузере и дымовой — в остальных, и обычно это верный компромисс.
Когда запускать UI-тесты?
На каждый pull request. Реже — и упавший тест будет указывать на пачку изменений, а не на одно.
Тестируйте в UI сценарии, всё остальное — уровнем ниже.
UI-тестирование должно покрывать сквозные сценарии, состояние между шагами и то, соответствует ли сказанное пользователю тому, что произошло на самом деле. Валидации, вычислениям и подготовке данных место уровнем ниже, где они быстрее и проще в диагностике.