Перевод статьи «The most complicated automated tests».
Так ли легко писать и поддерживать UI-тесты? Действительно ли модульные и интеграционные тесты являются самыми сложными?
В этой статье я расскажу о том, какие тесты являются самыми сложными и почему.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
С чего все началось?
В начале своей карьеры в области автоматизации тестирования я полностью сосредоточился на UI-тестах. Затем, спустя некоторое время, я познакомился с искусством тестирования API и начал писать такие тесты везде, где это было возможно (где существовало API).
Но в первое время, сколько бы я ни писал автоматизированных тестов, мне всегда казалось, что мои тесты слишком простые. Хорошие тестировщики пишут сложные и страшные модульные и интеграционные тесты. Чтобы написать такие тесты, нужно знать языки программирования и фреймворки.
Эти мысли не выходили у меня из головы до тех пор, пока я не решил посмотреть на фреймворки для модульного тестирования и сами модульные тесты в одном из проектов на работе.
Модульные тесты
С одной стороны, кажется, что юнит-тесты писать сложно. Но все становится гораздо проще, когда ты начитаешь понимать, в чем суть таких тестов, и осваиваешь хотя бы базовые возможности любого тестового фреймворка (например, JUnit).
При модульном тестировании мы сосредотачиваемся на уровне отдельных классов (или группы взаимосвязанных классов). Основное назначение – проверить правильность работы бизнес-логики. Для этого мы можем использовать фреймворк, такой как Mockito, чтобы имитировать все внешние вызовы и зависимости.
Если разобраться, как правильно писать mocks, то скорость создания новых тестов зависит только от сложности бизнес-логики самого класса. Что касается поддержки таких тестов, то это тоже несложно: такие тесты тесно связаны с функциональным кодом, поэтому их приходится часто менять.
Сложность реализации модульных тестов также невысока, так же как и затраты на их обслуживание. Единственный вопрос заключается в том, насколько хорошо поддаётся тестированию код функционала приложения.
Ключевым моментом в модульных тестах является то, что тестировщик полностью контролирует среду, тестовые данные и поведение зависимостей.
Интеграционные тесты
Интеграционное тестирование – одна из самых дискуссионных тем среди QA-инженеров.
Под интеграционными тестами подразумевается тестирование отдельных компонентов в отрыве от всей системы. Например, когда у нас много микросервисов на бэкенде, интеграционный тест может быть как на уровне сервиса (мы проверяем бизнес-логику сервиса в целом, так и на более детальном уровне – проверяем работу сервиса с базой данных).
В этом случае мы имитируем запросы к другим сервисам или компонентам с помощью Wiremock. Другие зависимости могут быть запущены локально в Docker-контейнерах.
Такие тесты показывают более реалистичную картину работы системы и ее компонентов.
Сложность реализации таких тестов средняя. Основная проблема здесь заключается в правильной настройке зависимостей для сервиса.
Если ваши тесты и код приложения разработаны правильно, то связи (интерфейсы) между разными компонентами приложения будут устойчивыми и надежными. Это делает вашу систему менее зависимой от конкретной базы данных или брокера сообщений.
Таким образом, если вам приходится менять базу данных или брокер сообщений, это не должно серьезно влиять на основную логику вашей системы или службы. Система останется стабильной и надежной, несмотря на изменения в зависимостях.
End-to-End тесты
Под end-to-end тестами я подразумеваю как тесты пользовательского интерфейса, так и тесты API. Главное в таких тестах – это то, что мы работаем с системой как пользователь. Такие тесты также можно назвать “черным ящиком“.
Как только вы освоите Selenium Webdriver и научитесь использовать паттерны Page Object (и другие), реализация сквозных тестов станет очень простой. Конечно, могут быть исключения: очень сложная и запутанная логика или нестандартные API. Создание UI-тестов не представляет особой сложности (по сравнению с юнит- и интеграционными тестами). Поэтому все считают, что сквозные тесты – самые простые.
Но дело в том, что автоматизированное тестирование – это не только внедрение новых тестов. Это еще и сопровождение таких тестов и отладка. Здесь кроется самый большой подводный камень (почти айсберг) в восприятии сквозного тестирования.
На производительность и стабильность таких тестов влияет множество внешних и внутренних факторов:
- Базы данных могут выполнять медленную репликацию и возвращать противоречивые данные.
- Сотни или тысячи внутренних микросервисов могут прекратить работу в любой момент (что приведет к большим проблемам).
- Критически важные сервисы могут получать данные от брокера сообщений (например, Kafka) с задержкой.
- Сторонние сервисы также могут работать нестабильно или быть полностью недоступными.
- Система может подвергаться воздействию DDoS-атак.
- Балансировщики нагрузки также могут быть нестабильными.
- Веб- или мобильные приложения могут работать по-разному (в зависимости от модели телефона или версии браузера).
- Фреймворк для тестирования может работать нестабильно (особенно при параллельном выполнении большого количества тестов).
Учитывая все эти скрытые моменты, руководство и даже другие члены команды по тестированию все равно ожидают почти 100% стабильности UI-тестов.
Но реальность сурова. Когда какой-нибудь тест пользовательского интерфейса дает сбой, его необходимо тщательно проанализировать и исправить. Если у вас есть специальная команда по автоматизации, то она должна не только понять, в какой момент теста возникла проблема, но также изолировать проблему и сообщить о ней команде разработчиков для немедленного устранения.
Иногда исправление происходит на уровне UI-тестов или фреймворка. Иногда это изменение требований или срочная необходимость обновления тестовых данных.
Но во многих случаях исправление не может быть выполнено немедленно, особенно если первопричина неясна и требует времени для анализа. У команды разработчиков есть свои приоритеты и задачи.
Как инженер по автоматизации тестирования, вы не контролируете систему и ее зависимости. Ваш инструмент – это браузер, и все!
Итак, какие тесты автоматизации являются наиболее сложными?
Я не утверждаю, что какие-то тесты избыточны или не приносят пользы. Я просто хочу подчеркнуть, что после того, как вы потратите некоторое время на изучение модульных и интеграционных тестов, писать такие тесты станет для вас относительно простой задачей. Вот почему нам необходимо иметь больше тестов на этих уровнях.
Сквозные тесты могут как приносить пользу, так и быть самыми сложными в сопровождении автоматизированными тестами. Это может быть огромным разочарованием для инженеров по автоматизации.
Ожидаете ли вы стабильные UI-тесты от команды автоматизации?