Как стать автором
Обновить

UI тесты — всегда ли нужны?

Время на прочтение 2 мин
Количество просмотров 41K
image

Тема этого поста будет посвящены тестированию, как таковому, и UI тестированию компонентов на клиентских приложениях, например приложений использующих Angular.js и иже с ними.

Какие же типы тестирования наиболее популярны на данный момент для клиентских приложений?

  1. Unit — базовый, я бы даже сказал — ОБЯЗАТЕЛЬНЫЙ. уровень тестирования. Предназначен для того, чтобы проверить, что весь базовый функционал компонентов, сервисов, и т.д., работает исправно и выполняет свою задачу.
  2. UI — тестирования уже самого интерфейса приложения, всех его свистелок и “не багов, а фич”. Заключается в том, что мы имитируем действия пользователя — клики, переходы по ссылкам, и другие действия подобного плана. Смысл его — в проверке взаимодействия компонентов друг с другом.
  3. E2E — выполняет похожие с UI тестированием функции, но с одним НО, всех тесты гоняют с реальными сервисами, API, BE.

Поскольку, заставить программиста писать даже Unit тесты, это уже Сизифов труд, то до UI & E2E добираются лишь спартанцы от мира программирования. Причем отсутствие тестов я видел, как в маленьких стартапах, так и в больших корпорациях.

Я и сам покрывал всеми тремя видами тестов приложения, но, в свое время, задумался: “А можно ли просто покрыть все большим количеством Unit тестов и небольшим — E2E?”. Давайте, попробуем разобраться.

Основные плюсы UI тестирования:

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

Основные минусы UI тестирования:

  • Огромное, иногда — невероятно огромное, количество времени, потраченного на mock всех компонентов и сервисов (впрочем, как и в Unit тестах).
  • Мало применимо для маленьких по размеру приложений, поскольку овчинка выделки не стоит.
  • Сами тесты гоняются дольше, чем Unit, из-за сложности используемых сервисов.
  • Более сложный процесс автоматизации и интеграции в pipeline (на Jenkins, Travis, etc.)

Первый, и самый главный, вопрос — определитесь с размером своего приложения. Если оно небольшое или короткосрочное — можете смело оставлять UI тесты за бортом, поскольку Вам хватит Unit + E2E.

Второе, более важное, что делать в случае, если у Вас огромный монстр, который просто необходимо проверить максимально дотошно? И ответ есть — больше Unit тестов!

Ведь в реальном мире, за каждым действием стоит изменения состояния приложения или компонента, будь-то функциональное или ОО программирование, и т.д. Любое действие пользователя должно чем-то заканчиваться, должен быть результат. И с помощью Unit тестов можно всегда проверять результат действия, а с помощью E2E — проверять взаимодействие компонентов.

Example:

  • Use case: Пользователь должен залогиниться через OAuth и попасть на Hello page.
  • App:
    LoginComponent:
        login: () => {   
            let isLogged = oauth.login();
            if (isLogged) {
                router.changeState(‘hello-board’); 
            } else {
                showError(error);	
            }
         }
  • Test case:
    • Unit test: Проверить была ли вызвана функция login(). Если “login()” была вызвана и Router сменил свой внутренний state на “hello-board” — значит все впорядке.
    • E2E test: Проверить была ли нажата та самая кнопка “Login” и был реально послан запрос на oauth и перешел ли юзер на верную страницу “Hello” путем проверки браузерной строки юзера после запроса.

P.S. Открыт для любых комментариев и оно крайне приветствуются!

P.S.S. Спасибо за Ваше время!
Теги:
Хабы:
+2
Комментарии 5
Комментарии Комментарии 5

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн