Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова.

В этой части ретроспективных уроков автоматизации я постараюсь сконцентрироваться на другом ключевом вопросе – что имеет смысл автоматизировать? Почему именно это, а не то? Зачем люди тратят столько времени на UI-тесты? Чтобы перейти к этим вопросам, поговорим об интерфейсах.

Что такое интерфейс?

Что же это на самом деле? Мы пользуемся этим каждый день: такой интерфейс, сякой, UI, GUI, голосовой, но что же это? Этот вопрос я люблю задавать своим студентам, чтобы они задумались над терминологией, которую они принимают как должное – как и множество опытных тестировщиков.

Итак, загуглите, что такое интерфейс, и вы, скорее всего, увидите нечто похожее на это определение:

"В информатике интерфейс – это общая граница между двумя или более отдельными компонентами компьютерной системы, обменивающихся информацией".

Дабы дать этому определению более широкий контекст, перефразирую его так:

"Интерфейс – это общая граница, средство, при помощи которого две системы обмениваются информацией".

Интерфейсы бывают разных типов и форм. Существуют хардварные (физические) интерфейсы – например, RJ45 (соединительный кабель) или HDMI, а также графические пользовательские, интерфейсы командной строки, голосовые, как у Google-помощника, сенсорные, и т. д.

Интерфейсы специфичны рядом общих для них характеристик:

1. 1. Интерфейсы скрывают сложность.

Это забавно, но даже в программировании мы используем интерфейсы, чтобы спрятать сложность. Если мы сталкиваемся с классом, использующим интерфейс ICountable, то уже знаем, что у этого класса есть ряд особых функций, которые можно использовать – если, конечно, мы знаем, что значит ICountable. Нам не нужно разбираться во внутренней кухне этого класса – мы знаем, какого поведения ожидать.

Теперь давайте взглянем на реальные примеры – когда мы видим интерфейс, мы знаем, что делать, не имея нужды беспокоиться, как оно работает изнутри. Посмотрите на ваш экран (на который вы и так смотрите) – как движется по нему ваша мышь? Надо ли вам знать, как она устроена, чтобы ей пользоваться? Нет, вы просто знаете, что когда вы двигаете мышь, срабатывает магия, и маленький курсор на вашем экране движется соответственно. Аналогично работают электрические розетки, HDMI, клавиатуры, сенсорные экраны…

1. 2. Интерфейсы внятно побуждают к действию.

Другая интересная характеристика интерфейсов – это то, что они ясно сообщают нам, как их использовать. К примеру, у вас есть кабель RJ-45, и вы знаете, что вам нужно нечто похожее, чтобы воткнуть его туда. Вы можете попытаться вставить туда HDMI, но это не сработает, как бы вы ни пытались.

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

1. У интерфейсов есть очень четкая задача. Если вы используете их неверно, то, скорее всегО, будете выглядеть идиотом.

Ранее я говорил, что интерфейс – это граница между двумя системами. Они специально созданы так, чтобы внятно общаться с этими системами без помех. Поэтому при неверном использовании интерфейса вы рискуете выглядеть глупо.

Представьте, что случится, если вы попытаетесь поговорить с сенсорным интерфейсом, у которого нет микрофона? Ничего. И вы выглядите как идиот.

Чувствуете, куда я клоню? Придержите эту мысль, я к ней еще вернусь.

Какое отношение это имеет к тестированию?

Это важный вопрос – почему я несу всю эту чушь про интерфейсы? Как тестировщики (странно, но факт), мы пользуемся интерфейсами для взаимодействия с продуктом, нравится вам это или нет. Шокирующая новость!

Если вы следите за этим циклом статей, вы, возможно, читали статью про уровни автоматизации. Если нет, я надеюсь, что вы знаете, что автоматизировать можно не только UI. В своей статье я перечислил несколько уровней – код (юнит и интеграция), служебный уровень (или API) и уровень UI. Итак, давайте посмотрим, что они предлагают нам в плане интерфейсов.

Уровень кода – не то чтобы интерфейс, но дает возможность манипулировать им напрямую

Предназначен ли для управления через код? Конечно! Этим код и занимается – управляет другим кодом!

Насколько он быстр и эффективен? Крайне! Это просто код, он быстр и эффективен настолько, насколько ему позволяет компилятор или интерпретатор.

Имеет ли смысл его автоматизировать? Да, конечно, этим уровнем легко манипулировать через код, и тесты быстро прогоняются.

Служебный уровень/API

Это уже интерфейс – это даже отражено в его имени (Application Programming Interface).

Предназначен ли для управления через код? Опять же, взглянем на его имя – Programming. API были созданы для управления через программы, то есть код.

Насколько он быстр и эффективен? Он очень эффективен. Будучи созданным для манипуляций через программы, API предоставляют похожий на протоколы способ взаимодействия с собой и получения реакции. Все реакции очень однозначны – нет сомнений, прошел ваш тест или упал.

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

Имеет ли смысл его автоматизировать? Да. его легко использовать, а его ответы легко интерпретировать автоматически.

Уровень UI / пользовательский интерфейс

Да, это вновь интерфейс, один из наиболее распространенных. На самом деле существуют пользователи, которые понятия не имеют, что с приложением можно взаимодействовать как-то иначе.

Давайте вернемся к моей тираде про интерфейсы. Я сказал, что это граница между двумя системами. Будет ли пользователь такой системой? Да, конечно, и очень сложной! Будет ли пользователь машиной? Вряд ли. Даже если он машина, мы не конструируем интерфейсы для этого случая.

Предназначен ли для управления через код? На этом этапе ответ на этот вопрос должен быть самоочевидным. Конечно, нет. Пользовательский интерфейс – это интерфейс для пользователя, который в норме человеческое существо. Однако мы можем создать инструменты и абстракции, позволяющие манипулировать интерфейсом через код.

Насколько он быстр и эффективен?

Держите в уме, что он не предназначен для манипуляций через код, и чтобы это сделать, мы строим дополнительный уровень абстракций. Это дается небесплатно – это медленно, сложно, и более склонно к ошибкам.

Имеет ли смысл его автоматизировать?

Не особенно. Почему? Как бы вы себя чувствовали, используя голосовые команды на клавиатуре? Как полный идиот?

Как бы вы себя чувствовали, создавая код, чтобы манипулировать интерфейсом, созданным для человеческих и только человеческих манипуляций?

Дабы лучше визуализировать этот момент, использую пример, о котором я недавно слышал. И птица, и самолет летают, не так ли? И самолеты были сконструированы по образцу птиц, однако чтобы заставить самолет лететь, не надо заставлять его хлопать крыльями.

Создание кода для тестирования пользовательских интерфейсов путем имитации пользовательского взаимодействия – это конструирование самолета, который хлопает крыльями. Это просто неэффективно.

Но люди это делают!

И на это есть веские причины – это полезно, и вот почему:

• Можно убедиться в функциональной правильности наших UI-компонентов. У вас может быть гениальное API и идеальная бизнес-логика, но если ваш UI не работает, то всем пофиг на ваш гений. UI – это то, с чем взаимодействует пользователь.
• Можно тестировать ближе к пользователю. В своей предыдущей статье я упоминал, почему так важно тестировать через UI – так мы лучше видим значимость найденных проблем.
• Мы используем UI-тесты, как ловушку, или детекторы изменений. В норме мы раскладываем наши тесты-ловушки вокруг продукта в надежде, что они заорут, если случится что-то плохое. Как и в случае с ловушками, сигнал от теста не означает, что мы в безопасности – он значит только, что нам нужно исследовать вопрос.

Хороши ли UI-тесты в качестве кандидатов на длинные тесты? Подумайте над всем вышесказанным. НЕТ, черт побери, нет, пожалуйста, не делайте этого во имя всего святого. Так и рождаются нестабильные тесты. Понятия не имею, чьей гениальной идеей были E2E-тесты, я в них не верю и не думаю, что овчинка стоит выделки.

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

Какой вывод мы можем сделать?

Тестировать можно массой различных прекрасных способов – простых, сложных, и очень сложных. Это контринтуитивно, однако в автоматизации мы выбираем самый сложный путь и делаем его стандартом для навыков автоматизатора. Мне это кажется забавным, но я убежден, что есть куда лучшие способы вклада времени в автоматизацию, чем чисто UI. Однако автоматизировать UI имеет смысл – но мы должны быть осторожными.

Надеюсь, тем, кто пытается разобраться, что, черт возьми, делать с этими тестами, поможет моя статья.

Обсудить в форуме