Пишем автотесты эффективно — Subcutaneous tests
Давайте представим себе гипотетическую ситауацию (в которую мы регулярно, вляпываемся). Вас назначили на проект «запилить» автоматизацию. Вам дают огромный тест план с большим количеством (тысячи их!) «ручных» тестов, и говорят что надо что-то сделать, и вотпрямщас. А еще, чтоб быстро и стабильно.
Писать Unit тесты, или даже думать о TDD — уже поздно, код продукта давным-давно написан. Ваше слово, товарищ автотестер!
К счастью, есть небольшой трюк, который позволит и coverage повысить, и сделать тесты стабильными и быстрыми — Subcutaneous tests («подкожные тесты»), но обо всем по порядку.
Суть проблемы
Первый условный рефлекс автоматизатора — это взять Selenium (ну, или там, Selenide, или еще какую вундервафлю для UI тестов). Это такой стандарт индустрии, но есть много причин, почему «не взлетит»:
Альтернативное решение
В качестве очень простого случая, давайте рассмотрим приложение, состоящее из формы, куда можно ввести валидное имя пользователя. Если вы ввели имя пользователя, соответствующее правилам — User будет создан в системе и записан в Базу Данных.
Исходный код приложения можно найти здесь: github.com/senpay/login-form. Вы были предупрежденны — в приложении куча багов и нет модных тулов и фреймворков.
Если попробовать «накидать» чек лист для данного приложения, можно получить что-то вроде:
| Number | Steps | Expected results |
|---|---|---|
| 1 | 1. Enter a valid user name 2. Click «Log in» button | 1. 2. A new user is created. |
| 2 | 1. Enter an empty user name 2. Click «Log in» button | 1. 2. The error message is given. |
Выглядит просто? Просто! Можно ли написать UI-тесты? Можно. Пример написанных тестов (вместе с полноценным трехуровневым фреймворком) можно найти в LoginFormTest.java если перейти на uitests метку в git (git checkout uitests):
Немного метрик для данного кода:
Время выполнения:
12 секунд (12 секунд 956 миллисекунд в последний раз, когда я запускал эти тесты)
Покрытие кода
Class: 100%
Method: 93.8% (30/32)
Line: 97.4% (75/77)
Теперь давайте предположим, что Функциональные автотесты могут быть написаны на уровне «сразу под» UI. Эта техника и называется Subcutaneous tests («подкожные тесты» — тесты, которые тестируют сразу под уровнем логики отображения) и была предложена Мартином Фаулером достаточно давно [1].
Когда люди думают о «не UI» автотестах, зачастую они думают сразу о REST/SOAP или иже с ним API. Но API (Application Programming Interface) — куда более широкое понятие, не обязательно затрагивающее HTTP и другие тяжеловесные протоколы.
Если мы поковыряем код продукта, мы можем найти кое-что интересненькое:
Когда мы кликаем что-то на UI — вызывается один из этим методов, или добавляется новый объект User, или возвращается список уже созданных объектов User. Что, если мы используем эти методы напрямую? Ведь это самый настоящий API! И самое главное, что REST и иные API тоже работают по тому же принципу — вызывают некий метод «уровня контроллера».
Используя напрямую эти методы, мы можем написать тест попроще да получше:
Этот код доступен по метке subctests:
Попробуем собрать метрики?
Time to execute:
21 milliseconds
Покрытие кода:
Class: 77.8%
Method: 78.1 (30/32)
Line: 78.7 (75/77)
Мы потеряли немного покрытия, но скорость тестов выросла в 600 раз.
Насколько важна\существенна потеря покрытия в данном случае? Зависит от ситуации. Мы потеряли немного glue code, который может быть (а может и не быть) важным (рекомендую в качестве упражнения определить, какой код потерялся).
В итоге
Версия статьи на Английском языке доступна здесь.
Если формат видео для вас больше подходит — можно посмотреть презентацию:
Можно также подписаться на мой Youtube канал тут.
Автотесты – барское дело
Зачем разработчикам писать автотесты? С таким же успехом их можно заставить класть плитку или вести бухгалтерию. Не барское это дело! Или, все-таки, барское?
Примечание: в статье под автотестами имеются ввиду не unit-тесты, а автоматизированные функциональные тесты, выполняющиеся на полностью развернутом продукте в окружении, максимально приближенном к боевому.
В разработке программного обеспечения существует много мифов и глупостей. Рассмотрим два из них.
Так уж сложилось, что тестировщики в индустрии в среднем зарабатывают меньше, чем разработчики. Происходит это, видимо, из-за того, что бытует мнение, что на роль тестировщиков можно нанять студентов по три рубля пучок, показать им куда надо «тыкать» — и все, команда обезьяно-тестеров готова. Это ерунда, конечно. Хороший тестировщик является по сути опытным хакером-педантом с не дюжим интеллектом и должен стоить дорого, но это почему-то мало кто понимает.
Вторая глупость – это отношение к автотестам. Считается, что разработка автотестов – это тупая нудная работа, которую можно и нужно поручать кому угодно, кто согласится её выполнять, так как пользователю и заказчику на автотесты вообще плевать, ему продукт нужен.
Вторая причина вытекает из того, что команда тестирования не владеет продуктовым кодом. Кодом владеют разработчики и только они могут вносить в него исправления.
Из практики применения юнит-тестов известно, что их разработка наиболее эффективна тогда, когда занимается ей автор тестируемого кода. В этом случае код, как правило, получается более пригодным для тестирования и в результате тесты выходят проще и надежнее.
Точно такая же ситуация имеет место быть и при разработке функциональных автотестов. Когда продуктовый код пишут разработчики, а тесты для этого кода тестировщики, то трудоемкость и качество (поддерживаемость, скорость выполнения, хрупкость и пр.) таких тестов получается хуже, чем если бы и то и другое разрабатывала одна команда. Это происходит из-за того, что разработчик имеет возможность слегка подправить код так, чтобы ему самому было удобнее для этого кода написать автотест. Теоретически, инженер из команды тестирования тоже может попросить команду продуктовых разработчиков модифицировать код. Но на практике, это происходит не всегда, так как часто тестировщику проще оставить в тесте костыль (например, sleep), чем обращаться с просьбой к команде разработчиков, которые в данный момент заняты чем-то важным, ждать пока они реализуют то, что ему нужно, потом получить не то, что он просил и так по кругу. В результате, со временем тесты обрастают костылями, становятся неподдерживаемыми и превращаются в тот самый чемодан без ручки, который и выбросить жалко и тащить тяжело.
Таким образом, самые надежные и легко поддерживаемые тесты получаются, когда их делает команда продуктовых разработчиков. Но данный вариант также не лишен недостатков. Эти недостатки хорошо известны и благодаря им вообще существуют тестировщики. Все в конечном итоге сводится к тому, что тестировщики лучше находят ошибки.
Поэтому оптимальным является некоторый промежуточный вариант, когда автотесты пишутся и разработчиками и тестировщиками. При таком комбинированном подходе удается объединить сильный стороны тех и других. Разработчики закладывают грамотную архитектуру автотестов, адаптируют продукт и обеспечивают покрытие тестами продуктового кода. Тестировщики, со своей стороны, обеспечивают покрытие тест-кейзов, используя в качестве базы автотесты разработчиков.
Разработка автотестов является у нас неотъемлемой частью общего процесса разработки продукта. При планировании итерации для каждой пользовательской истории мы обязательно закладываем время на подготовку автотестов для неё. Трудоемкость автотестов обычно составляет 10-20% от трудоемкости истории, но потраченное время потом многократно окупается.
При внедрении такого подхода к разработке автотестов могут быть проблемы с мотивацией разработчиков, но преодолеть эти проблемы не сложно. Надо сделать так, чтобы прогон автотестов (по крайней мере, части из них) стал внутренним делом команды программистов. Это означает, что тестировщики получают в тестирование только те сборки, на которых полностью прошли автотесты. При этом, на сломанный функционал, который был обнаружен автотестами, не заводятся баги, так как тестировщики про этот позор ничего не знают. Если программист чекинит код, который ломает автотесты, то он либо сразу откатывает чекин, либо быстро его чинит, если там какая-то мелочь.
Потом остается только контролировать и поддерживать регулярные занятия автотестами, чтобы опять не завалиться на диван и не заплыть жиром.
7 лучших языков программирования для автоматизации тестирования
Автоматизированное тестирование экономит силы тестировщиков, но для его запуска нужно уметь программировать. Разбираемся, какие языки стоит учить Quality Assurance в 2020 году.
1. Python
Python — язык программирования с открытым исходным кодом, его используют в веб-разработке, создании десктопных и мобильных приложений, автоматизации тестирования, машинном обучении. В опросе Stack Overflow Developer Survey 2019 года, 73,1% разработчиков назвали Python в числе любимых языков программирования.
2. Java
Java — объектно-ориентированный язык общего назначения. Он основан на принципе WORA, или «Напиши один раз, запускай везде». То есть написанное на Java приложение можно запускать на любой платформе, где установлена среда исполнения Java.
Хотя JUnit — популярная библиотека для модульного тестирования, существуют фреймворки с открытым исходным кодом для автоматизированного тестирования на Java. Так, автоматизированное браузерное тестирование веб-продукта можно выполнить, используя JUnit с Selenium WebDriver.
3. JavaScript
В опросе Stack Overflow Developer Survey 2019 года JavaScript занял первое место в рейтинге «Языки программирования, сценарии и разметки». Он стал популярным для автоматизации тестирования, по всей видимости, из-за распространения стратегии Shift Left, при которой команда тестирования тесно сотрудничает с командой разработки.
C# — объектно-ориентированный язык, подходит для автоматизированного тестирования приложений, работающих на Android, Windows и iOS.
Поскольку язык совместим с Selenium WebDriver, многие тестировщики выбирают C# для автоматизированного и кросс-браузерного тестирования. Используя шаблон проектирования Page Object Model (POM), тестировщики могут разработать код, легко поддающийся изменениям и дополнениям. Среди фреймворков, которые используют для автоматизированного тестирования с C#, — NUnit, MSTest и xUnit.Net.
5. Ruby
Ruby — еще один язык программирования, который становится популярным для автоматизации тестирования и автоматизированного браузерного тестирования.
Как и Python, Ruby несложен в изучении, а простой синтаксис и гибкая объектно-ориентированная архитектура делают его мощным языком программирования. Еще одна причина популярности языка — растущее комьюнити разработчиков на Ruby.
6. PHP
PHP — серверный скриптовый язык программирования, предназначенный для веб-разработки, но его используют и для автоматизации тестирования. PHP не такой сложный, как другие языки для backend-разработки, например, Python или Java.
Расширение XDebug — мощный инструмент для отладки и профилирования. Он поддерживает несколько фреймворков для автоматизации тестирования, например: Laravel Dusk, Codeception, PHPUnit и BeHat.
ТОП-5 вопросов начинающего автоматизатора про автотесты
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
А пока мы не перешли к торжественной части, было бы круто, если бы вы помогли нам в нашем исследовании:
Каждый год мы изучаем технобренд крупных и не очень игроков российского IT-рынка. Выясняем, кого знают меньше или больше, куда пойдут работать охотнее и почему. Результатами обычно делимся прямо здесь, на Хабре.
Пожалуйста, пройдите этот опрос и помогите изучить рынок IT в 2021 году.
Вопрос 1. Мы пишем и прогоняем автотесты, а баги с прода все равно прилетают.
Начнем с того, что баги с прода продолжат прилетать в любом случае, и это совершенно нормально.
Пользователи могут совершать с вашим приложением невообразимые действия и проходить невероятные, непредсказуемые сценарии — открыли, перешли в другое приложение, заблокировали телефон, получили пуши, где-то полистали новости и решили вернуться в наше приложение. И вот тут-то баг его и поджидает. Частично такие кейсы можно автоматизировать — с помощью нагрузки, прерываний и выгрузки в фон и т.п. Но все возможные уникальные сценарии покрывать автотестами точно не стоит. Как минимум потому что ни один CI не выдержит такой загрузки, а время тестового прогона не будет того стоить.
Также могут быть девайс-зависимые баги, которые невозможно отловить автотестами, если вам не повезло тестировать именно на этом устройстве. Можно, конечно, попробовать настроить CI так, чтобы он создавал разные эмуляторы, или гонять автотесты на разных реальных девайсах, но это значительно увеличит сложность поддержки таких автотестов и скорее всего снизит их стабильность. И, опять же, это не будет стоить увеличенного времени на поддержку и прогоны, особенно с учетом, что находимые баги будут минорными.
Вопрос 2. Как сделать так, чтобы автотесты не заставляли всех страдать?
Чтобы автотесты не заставляли страдать всех вокруг, достаточно следовать некоторым правилам:
Правило 1. Писать понятный читаемый код, настроить отчеты.
Тесты должны быть понятны не только вам, но и другим тестировщикам и разработчикам. Если ваш тест упал, то человек не должен сидеть над ним полдня или сразу идти к автору автотеста с “помоги, посмотри почему он упал”, а должен сам понимать место и причину падения. Еще лучше, если у вас настроены человекочитаемые отчеты, в которых также видны шаги и место, где и почему упал тест.
Никому не хочется тратить время на то, чтобы понять, как автотест работает и что он там вообще проверяет — всё должно быть прозрачно.
Правило 2. Обязательное ревью.
Чтобы убедиться в том, что ваш тест действительно полезен и идеален, нужно, чтобы кто-то еще это подтвердил, и тогда можете спать спокойно.
У нас в hh для всех задач предусмотрено обязательное ревью. Для всех задач с автотестами предусмотрено обязательное ревью от QA. Это крайне важно, так как ревьювер может найти не только неправильный отступ, но и ошибки в логике, посоветовать добавить какие-либо дополнительные проверки, или указать на то, что вы запросто могли пропустить.
Правило 3. Сразу внедрять автотесты в ваш CI/CD
Очень важно, чтобы автотесты сразу приносили пользу, а не ждали лучших времен где-то в недрах кода. Чем быстрее все начнут привыкать, что их код теперь тестируется, тем проще всем станет жить. При этом важно не забывать, что выпускать автотесты нужно максимально стабильными. Перед тем, как вмержить свои тесты, лучше в прямом смысле 100 раз прогнать их на CI. И только убедившись на 100%, что тест не флакует, не падает неожиданно в разных местах, работает и работает как надо — сразу вперед!
Вопрос 3. Из-за чего тесты постоянно падают? Как можно им доверять?
Начнем с того, что какие-то автотесты в любом случае будут падать. Это совершенно нормально, так как если они в 100% случаев всегда зеленые, стоит задуматься — а проверяют ли они вообще что-то?
Но со своей стороны мы обязательно должны сделать максимум для того, чтобы падали они как можно реже. Для этого нужно научиться быстро понимать и устранять причины падений и улучшать слабые места.
За время работы с автотестами я выявила свой личный ТОП-4 проблем с автотестами:
1 — Кто-то что-то выкатил и все упало
Тут все просто — изменения в функционале должны идти рука об руку с правкой автотестов. На такие правки мы закладываем время при оценке и декомпозиции задачи. Когда разработчик изменяет что-то в функционале, который уже был покрыт автотестами, перед тем как вмержить свою ветку, он должен поправить автотесты, чтобы они продолжали проверять этот функционал. Очень важно наладить этот процесс, не игнорить тесты, а всегда поддерживать их актуальность.
2 — Тесты начали падать, но мы ничего не меняли
Тут интереснее. Разработчик ничего не менял, но в какой-то момент тесты начали падать. Возможно, что-то поменяли на бэке.
Почему наши UI-автотесты зависят от бэкенда?
Наши автотесты гоняются на тестовых стендах — это копия продового бэкенда (без продовой базы данных). Мы поддерживаем их актуальность — каждый день автотесты запускаются на актуальном бэкенде. Соответственно, если кто-то зарелизил что-то новое, наши автотесты об этом узнают и, как следствие, могут упасть. Мы в срочном порядке бежим смотреть: баг это или наша новая реальность, которую следует поддержать. И далее либо сообщаем команде о баге, либо правим тесты.
Тут важно заметить, что это случается не при каждом изменении на бэке. Всё-таки в основном, мы синхронизируемся командами по всем изменениям. Но реальность такова, что иногда какие-то моменты упускаются — кто-то не подумал, что может зааффектить мобильные приложения, например. Наши автотесты к такому чувствительны.
Каждый раз, когда такое случается, мы задумываемся о моках. Моки — это классно, если ими не злоупотреблять. Но всё-таки я думаю, что такая чувствительность автотестов к изменениям — это нормально, потому что там мы остаемся в курсе новых фич, которые влияют на наше приложение со стороны других команд. Плюс на моки тоже нужно выделять время на поддержку и актуализацию. Тут каждый сам выбирает, что ему больше хочется поддерживать.
3 — Баги
Моя любимая причина падения автотестов. Тут можно и без комментариев. Если ваш автотест нашел баг, то это очень хороший автотест, а вы — большой молодец.
4 — Флакование
А это самая нелюбимая причина. О ней поговорим далее.
Вопрос 4. Почему мои тесты флакуют?
Флакование как эмоциональные качели — ваши тесты то зеленые, то красные, всем то грустно, то радостно, и как с этим жить никто не знает. Чтобы отношения вашего приложения и автотестов были максимально здоровыми, советуем придерживаться нескольких правил о том, как избежать флакований и писать изначально более стабильные автотесты:
1. Уникальные тестовые данные
Для каждого автотеста должны создаваться новые уникальные тестовые данные, с которыми будет работать только этот тест. Нельзя надеяться на то, что на каком-то экране точно будет что-то, что мы сможем проверить и нам ок. Предсказуемость очень важна.
2. Не забывать дожидаться элементов на экране
Вы написали логичный тест, все четко по шагам, но тест не проходит и постоянно падает в разных местах. Скорее всего где-то он не успевает дождаться нужного элемента и тапает не туда, куда бы вам хотелось. Усугубляют ситуацию различные анимации, лоудеры загрузки и внезапные алерты.
Чтобы такого не случалось, перед каждым действием над элементом (тапы, свайпы и т.д.) или ассертом (проверкой, чеком) нужно дождаться, пока этот элемент точно появится на экране и будет доступен.
У Kaspresso для android есть встроенный механизм, который перед каждым действием под капотом дожидается элемент, делая ретраи на isVisible, и только потом совершает это действие. Благодаря этому, проблем с “тапами не туда” или “тапами раньше, чем нужно” в ваших автотестах больше не будет. Также этот вейтер можно настроить на нужное/необходимое вам количество времени, так как возможно дожидаться какой-то элемент по 10 секунд на экране — это уже баг.
В XCUITest на iOS также есть вейтеры из коробки, но проставлять их нужно вручную перед каждым действием. Либо стоит самим написать механизм, подобный каспрессовскому.
Главное не оставлять в коде вейты на конкретное количество секунд, так как это сильно увеличит время прохождения тестов. И взять за правило — прежде, чем что-то сделать с элементом, — убедитесь, что он есть на экране.
3. Настроить стабильную инфраструктуру
Если инфраструктура, на которой гоняются тесты, постоянно подводит, то стоит решать эту проблему как можно быстрее. Зависающие и тормозящие эмуляторы, падающие тестовые стенды — в такой атмосфере ваши прогоны тестов вряд ли будут зелеными, да и всем довольно быстро надоест разбирать причины их падений. Поэтому нужно обязательно выделить время и ресурсы команды на стабилизацию инфраструктуры. Если все оптимизировано по-максимуму, но все равно остаются проблемы, возможно вам стало не хватать существующего железа и пора лезть в бюджет за новым.
Вопрос 5. Что делать, когда тестов стало очень много?
В самом начале вы писали коротенькие простые автотесты — открой в приложении такой-то экран и проверь, что он отобразился. Затем вы начинаете автоматизировать более сложные сценарии, более сложные проверки. Количество тестов растет. Время прогона увеличивается. А когда что-то ломается, вместо одного теста у вас падает целых десять, и все с одинаковой ошибкой. При этом время упавшей сборки увеличилось в несколько раз, так как упавшие тесты еще и ретраились.
В такой ситуации важно не держаться за свои старые, пусть даже стабильные, тесты и уметь их отпускать. Удаляйте их, если такие же проверки появились в новом. Железо не резиновое, а тратить х2 времени на запуск приложения для каждого нового теста контрпродуктивно и не экономично.
Чтобы не закапываться в будущие объемные рефакторинги, может помочь правило — актуализируй старое прежде, чем писать новое. Если вы сразу начинаете этому правилу следовать, то такой проблемы у вас возникнуть не должно.
Вместо заключения:
Эта статья — заключительная из серии ответов на вопросы про автоматизацию. Но мы продолжим рассказывать про тестирование и автоматизацию в hh.ru, о том, как проходят наши релизы и еще много о чем полезном и интересном.
А чтобы не пропустить новые видео, статьи и прочие новости, подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube. Также вы можете задать вопросы нашим инженерам по любым темам в комментариях, в телеграм-чате с разработчиками hh или в личку.
Ищем тестировщиков в четыре разных направления:
Пишем автотест с использованием Selenium Webdriver, Java 8 и паттерна Page Object
В этой статье рассматривается создание достаточного простого автотеста. Статья будет полезна начинающим автоматизаторам.
Материал изложен максимально доступно, однако, будет значительно проще понять о чем здесь идет речь, если Вы будете иметь хотя бы минимальные представления о языке Java: классы, методы, etc.
Создание проекта
Запустим Intellij IDEA, пройдем первые несколько пунктов, касающихся отправки статистики, импорта проектов, выбора цветовой схемы и т.д. — просто выберем параметры по умолчанию.
В появившемся в конце окне выберем пункт «Create New Project», а в нем тип проекта Maven. Окно будет иметь вид:
Нажмем «Next». Откроется следующее окно:
Groupid и Artifactid — идентификаторы проекта в Maven. Существуют определенные правила заполнения этих пунктов:
Нажмем «Finish»: IDE автоматически откроет файл pom.xml:
В нем уже появилась информация о проекте, внесенная на предыдущем шаге: Groupid, Artefiactid, Version. Pom.xml — это файл который описывает проект. Pom-файл хранит список всех библиотек (зависимостей), которые используются в проекте.
Для этого автотеста необходимо добавить две библиотеки: Selenium Java и Junit. Перейдем на центральный репозиторий Maven mvnrepository.com, вобьем в строку поиска Selenium Java и зайдем в раздел библиотеки:
Выберем нужную версию (в примере будет использована версия 3.14.0). Откроется страница:
Копируем содержимое блока «Maven» и вставим в файл pom.xml в блок
Таким образом библиотека будет включена в проект и ее можно будет использовать. Аналогично сделаем с библиотекой Junit (будем использовать версию 4.12).
Создание пакета и класса
Раскроем структуру проекта. Директория src содержит в себе две директории: «main» и «test». Для тестов используется, соответственно, директория «test». Откроем директорию «test», кликом правой клавиши мыши по директории «java» выберем пункт «New», а затем пункт «Package». В открывшемся диалоговом окне необходимо ввести название пакета. Имя базового пакета должно носить тоже имя, что и Groupid — «org.example».
Следующий шаг — создание класса Java, в котором пишется код автотеста. Кликом правой клавиши мыши по названию пакета выберем пункт «New», а затем пункт «Java Class».
В открывшемся диалоговом окне необходимо ввести имя Java класса, например, LoginTest (название класса в Java всегда должно начинаться с большой буквы). В IDE откроется окно тестового класса:
Настройка IDE
Прежде чем начать, необходимо настроить IDE. Кликом правой клавиши мыши по названию проекта выберем пункт «Open Module Settings». В открывшемся окне во вкладке «Sources» поле «Language level» по умолчанию имеет значение 5. Необходимо изменить значение поля на 8 (для использования всех возможностей, присутствующих в этой версии Java) и сохранить изменения:
Далее необходимо изменить версию компилятора Java: нажмем меню «File», а затем выберем пункт Settings.
Test Suite
Тест считается успешно пройденным в случае, когда пользователю удалось выполнить все вышеперечисленные пункты.
Для примера будет использоваться аккаунт Яндекс (учетная запись заранее создана вручную).
Первый метод
В классе LoginTest будет описана логика теста. Создадим в этом классе метод «setup()», в котором будут описаны предварительные настройки. Итак, для запуска браузера необходимо создать объект драйвера:
Чтобы ход теста отображался в полностью открытом окне, необходимо сказать об этом драйверу:
Случается, что элементы на страницах доступны не сразу, и необходимо дождаться появления элемента. Для этого существуют ожидания. Они бывают двух видов: явные и неявные. В примере будет использовано неявное ожидание Implicitly Wait, которое задается вначале теста и будет работать при каждом вызове метода поиска элемента:
Таким образом, если элемент не найден, то драйвер будет ждать его появления в течении заданного времени (10 секунд) и шагом в 500 мс. Как только элемент будет найден, драйвер продолжит работу, однако, в противном случае тест упадем по истечению времени.
Для передачи драйверу адреса страницы используется команда:
Выносим настройки
Для удобства вынесем название страницы в отдельный файл (а чуть позже и некоторые другие параметры).
Создадим в каталоге «test» еще один каталог с названием «resources», а в нем обычный файл «conf.properties», в который поместим переменную:
а также внесем сюда путь до драйвера
В пакете «org.example» создадим еще один класс «ConfProperties», который будет читать записанные в файл «conf.properties» значения:
Обзор первого метода
Метод «setup()» пометим аннотацией Junit «@BeforeClass», которая указывает на то, что метод будет выполняться один раз до выполнения всех тестов в классе. Тестовые методы в Junit помечаются аннотацией Test.
Page Object
При использовании Page Object элементы страниц, а также методы непосредственного взаимодействия с ними, выносятся в отдельный класс.
Создадим в пакете «org.example» класс LoginPage, который будет содержать локацию элементов страницы логина и методы для взаимодействия с этими элементами.
Откроем страницу авторизации в сервисах Яндекс (https://passport.yandex.ru/auth) в браузере Chrome. Для определения локаторов элементов страницы, с которыми будет взаимодействовать автотест, воспользуемся инструментами разработчика. Кликом правой кнопки мыши вызовем меню «Просмотреть код». В появившейся панели нажмем на значок курсора (левый верхний угол панели разработчика) и наведем курсор на интересующий нас элемент — поле ввода логина.
Для локации элементов в Page Object используется аннотация @FindBy.
Напишем следующий код:
Таким образом мы нашли элемент на страницу и назвали его loginField (элемент доступен только внутри класса LoginPage, т.к. является приватным).
Однако, такой длинный и страшный xpath использовать не рекомендуется (рекомендую к прочтению статью «Не так страшен xpath как его незнание». Если присмотреться, то можно увидеть, что поле ввода логина имеет уникальный id:
Воспользуемся этим и изменим поиск элемента по xpath:
Теперь вероятность того, что поле ввода пароля будет определено верно даже в случае изменения местоположения элемента на странице, возросла.
Аналогично изучим следующие элементы и получим их локаторы.
А теперь напишем методы для взаимодействия с элементами.
Метод ввода логина:
Метод ввода пароля:
Метод нажатия кнопки входа:
Для того, чтобы аннотация @FindBy заработала, необходимо использовать класс PageFactory. Для этого создадим конструктор и передадим ему в качестве параметра объект Webdriver:
После авторизации мы попадаем на страницу пользователя. Т.к. это уже другая страница, в соответствии с идеологией Page Object нам понадобится отдельный класс для ее описания. Создадим класс ProfilePage, в котором определим локаторы для имени пользователя (как показателя успешного входа в учетную запись), а также кнопки выхода из аккаунта. Помимо этого, напишем методы, которые будут получать имя пользователя и нажимать на кнопку выхода.
Итого, страница будет иметь следующий вид:
Интересный момент: в метод getUserName() пришлось добавить еще одно ожидание, т.к. страница «тяжелая» и загружалась довольно медленно. В итоге тест падал, потому что метод не мог получить имя пользователя. Метод getUserName() с ожиданием:
Вернемся к классу LoginTest и добавим в него созданные ранее классы-страницы путем объявления статических переменных с соответствующими именами:
Сюда же вынесем переменную для драйвера
В аннотации @BeforeClass создаем экземпляры классов созданных ранее страниц и присвоим ссылки на них. Создание экземпляра происходит с помощью оператора new. В качестве параметра указываем созданный перед этим объект driver, который передается конструкторам класса, созданным ранее:
А создание экземпляра драйвера приведем к следующему виду (т.к. он объявлен в качестве переменной):
Теперь можно перейти непосредственно к написанию логики теста. Создадим метод loginTest() и пометим его соответствующей аннотацией:
Осталось лишь корректно все завершить. Создадим финальный метод и пометим его аннотацией @AfterClass (методы помеченные этой аннотацией выполняются один раз, после завершения всех тестовых методов класса).
В этом методе осуществляется вход в меню пользователя и нажатие кнопки «Выйти», чтобы разлогиниться.
Последняя строка нужна для закрытия окна браузера.
Обзор теста
Запуск автотеста
Для запуска автотестов в Intellij Idea имеется несколько способов:
В результате выполнения автотеста, в консоли Idea я вижу, что тестовый метод loginTest() пройден успешно:
