Атомарный подход в тестировании
Хотите ускорить создание новых автотестов, заодно упростив поддержку старых? Постарайтесь избавиться от громоздких end-to-end-кейсов там, где это возможно. Это станет хорошим шагом на пути к оптимизации автотестирования на проекте.
Сами по себе end-to-end-тесты, разумеется, хороши. Однако бывают ситуации, когда необходимо поверить лишь один конкретный экран или даже конкретную часть информации, которая на этом экране находится. Согласитесь, довольно накладно проходить все стадии, начиная с авторизации пользователя.
Допустим, тестируемый продукт — это интернет-магазин, а нам надо проверить лишь чек, который будет отправлен покупателю после покупки конкретного товара. В случае с end-to-end-проходкой мы для получения одного-единственного экрана заходили бы по зарегистрированному паролю и логину, выбирали бы товар, потом подтверждали покупку и т. д. и т. п., то есть выполняли бы много шагов, которые, по большему счету, не связаны с конкретной задачей тестирования. При этом достаточно вспомнить, что каждый шаг занимает время, причем немалое. К примеру, проходка такого end-to-end-пути целиком может занять до 2 минут, тогда как проверка конкретного экрана – не более 10 секунд.
Именно поэтому целесообразно перейти к так называемым атомарным проверкам, которые обращаются лишь к тому экрану, который интересует нас в рамках прохождения тест-кейса.
Также для сравнения экранов можно внедрить snapshot-тестирование — оно позволит проверить большую часть UI. А уже имея тесты и код программного приложения в одном репозитории, вы сможете задействовать в тестах методы этого приложения. И, соответственно, находить ошибки при сравнении тестовых снимков экрана с эталонными снимками.
Подход со snapshot-тестами позволяет заметно уменьшить время проверки готовой версии приложения перед отправкой на продакшн. А весь набор таких тестов может запускаться автоматически при открытии pull request’а и прогоняться в течение часа, в результате чего разработчики быстро получат фидбек о проблемах в текущей ветке.
Конечно, определенное количество end-to-end-тестов на проекте быть должно. Но они оправданы лишь там, где нужна проверка больших бизнес-сценариев. Просто помните об этом.
По материалам https://habr.com/ru/company/maxilect/.
