Если вы используете maven для сборки (альтернатива - gradle), то вы можете легко сгенерировать примерный проект с помощью публичного архетипа selenide-junit5-archetype.
Выберите groupId (обычно домен компании в обратном порядке), и artifactId - (название проекта).
Проект создастся в папке указанной в artifactId. Его можно открыть с помощью IDE, на данный момент он состоит из 3 небольших классов и файла конфигурации pom.xml
1
cd ui-tests
Мы можем запустить тесты с браузером по умолчанию (Chrome)
Предлагаю к ознакомлению запись доклада-мастер класса, с примерами практического применения элементов KISS-Driven автоматизации в UI тестировании.
Слайды:
Довольно часто я получаю вопросы такого типа:
Слушал ваш доклад на <конференция>. Вы рассказывали про KISS и про много вещей которые не укладываются в голове, (отказ от наследования, дублирование кода...) но вот ни слова не рассказали о конкретно ваших показателях и какие у вас результаты. Поэтому хотел узнать: сколько у вас всего e2e тестов? Сколько времени они у вас длятся, какой самый длинный тест, сколько из этих тестов flaky? и сколько % времени вы тратите на "maintenance"? Спасибо.
Постараюсь ответить.
Я считаю, что все указанные вопросы абсолютно нерелевантны к теме как писать тесты. Аргументы:
Во-первых любая выборка от одного человека (даже учитывая применение на разных проектах) ничтожно мала, чтобы служить базисом для чего угодно.
Во-вторых различные проекты имеют различную специфику, поэтому какое-то усреднение количества тестов "в среднем по больнице" - бессмысленный источник для сравнения.
В-третих объективный научный подход было бы параллельное ведение несколькими одинаковыми по профессиональными уровню командами автоматизации тестов, когда одна команда разрабатывает и поддерживает одни и те же тесты по KISS принципам, а вторая строит деревья наследования PageObjects и описывает переходы между страницами, с использованием паттернов автоматизации. Сравнение метрик между обоими проектами на некоторой достаточно большой выборке могла бы являться объективным критерием превосходства одной из методик. Очевидно, что такие эксперименты неосуществимы на практике.
Попробую для программистов сделать несколько утрированную аналогию. Как вам помогают GoF Design Patterns? Сколько классов и пакетов вы написали этими паттернами в % к остальным? Сколько находится багов в этих классах? Как сложно находить там баги? Сколько % времени у вас уходит на поддержку кода с этими паттернами?
В целом успех проекта очень редко в достаточной мере зависит от успехов в автоматизации UI тестов. Моя оценка влияния разницы между отличными UI тестами и полным их отсутствием - <5% к вероятности успеха в целом (см. нестабильность тестов). Плохие UI тесты могут даже сильно тормозить проект и приносить вред по сравнению с отказом от них.
А для тех у кого есть праздный интерес к ничего не значащим вне контекста цифрам:
В разных проектах с моих участием было написано между 20 и 100 тестами.
Самый короткий - длится секунду, самый длинный минуты 3. 🙂
Настоящих flacky среди них очень мало, но это не благодаря KISS, а благодаря фреймворку Selenide, который очень хорошо решает многие проблемы со стороны тестов. В среднем по больнице около 5% тестов показывали разный результат на повторных прогонах, что в 99% случаев было связано с ошибками в софте.
Время на поддержку по KISS всегда уходит мало, статистику я не вёл. Один раз был случай, надо было поменять свести около 100 классов написаных копипастом в 5. Причина - нас дезинформировали о структуре кода страниц в разработке. Сперва утверждалось, что каждая страница (они были действительно подозрительно похожи друг на друга) является отдельным элемента в исходном коде, поэтому для упрощения поддержки написали класс на каждую такую "страницу" копипастом. Потому оказалось, что нет - как и показалось - один класс генерировал большие группы страниц, решили переделать. Рефакторинг занял примерно 4 часа.
И что? 🙂
По теме доклада я готов к ведению профессиональных дискуссий с применением логических аргументов. Переходящих на личности троллей я тут в комментах баню.
В субботу 23.04 буду в Москве на конференции по автоматизированному тестированию "QA Conference".
Я буду рассказывать про сравнительно узкую техническую тему - использование PageObjects в UI Automation.
И для заманухи - в докладе я покажу, в каких местах Copy&Paste кода - хорошая идея. 🙂
Этот и другие вбросы - в Москве, в гостинице "Салют" с 10 утра, приходите или смотрите online. Я думаю, что будет, как обычно, довольно живенько и спорно!
Эту ошибку при написании ui автотестов я, как мне кажется, встречаю чаще
всего.
Update. По просьбам трудящихся обновил пример с более абстрактного, на более жизненный. Суть осталось неизменной.
Представьте, у вас есть такой простой набор тестов.
1
2
Заполнить корзину товарами - убедиться, что существует кнопка, на которой написано "Оплатить"
Очистить корзину от товаров - убедиться, что существует кнопка, на которой написано "Оплатить" и она "disabled".
Набор чеков в коде, в стиле Selenide, будет примерно таким:
Java
1
2
3
4
5
6
7
fill_shopping_cart();
button.shouldBe(visible)
.shouldHaveText("Оплатить");
empty_shopping_cart();
button.shouldBe(visible)
.shouldHaveText("Оплатить")
.shouldBe(disabled);
Видите ошибку?
Если вы просто повторили язык теста, то чеки пройдут положительно и тест будет "зелёненьким", даже когда "Оплатить" будет всегда "disabled" (в частности, после выполнения заполнения корзины).
Более правильным, конечно, будет вариант
Java
1
2
3
4
5
6
7
8
fill_shopping_cart();
button.shouldBe(visible)
.shouldHaveText("Оплатить")
.shouldBe(enabled);
empty_shopping_cart();
button.shouldBe(visible)
.shouldHaveText("Оплатить")
.shouldBe(disabled);
Часто автоматизаторы оправдываются, что в тексте это не стояло - поэтому они и не сделали проверку, что виноват тестировщик составляющий текст теста. Это ерунда, потому что многие проверки являются очевидными при ручном тестировании и вписывать их в текст - неоправданная трата времени. Хороший автоматизатор должен понимать предметную область и кодировать такие "неявные" проверки самостоятельно.
В этом году я познакомился с фреймворком Selenide, который позволяет писать более компактные и читаемые тесты на языке Java с использование технологии Selenium Web Driver. Доклады на эту и другие темы автора фреймворка Андрея Солнцева показывают, что разработчики глубоко понимают проблемы UI тестирования и успешно работают над их решениями. Давайте же пользоваться!
Все хорошо, но есть проблема. Если посетить на сайте проекта раздел "Быстрый старт", то вам предложат воспользоваться одним из продвинутых тулов для разработчиков (maven, gradle, ivy). Необходимо ли это? Вовсе нет. Начать писать тесты и эффективно использоваться Selenide можно и владея только самым базисом тест-автоматизации - Java, Eclipse, основы Selenium. У вас есть 5-10 минут? Этого достаточно, убедитесь сами.