Тема этого поста будет посвящены тестированию, как таковому, и 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. Спасибо за Ваше время!