Предлагаю к ознакомлению запись доклада-мастер класса, с примерами практического применения элементов 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 часа.
И что? 🙂
По теме доклада я готов к ведению профессиональных дискуссий с применением логических аргументов. Переходящих на личности троллей я тут в комментах баню.