2. PECCATA MORTALIA ET VOLUPTATES REUS
Да не покажется сие странным, но автоматизаторы тоже
люди, а потому также подвержены различного рода
слабостям. Сегодняшняя проповедь – как раз о них.
Впрочем, мы не будем здесь расписывать всякие
скабрезности и ограничимся описанием
профессиональных грехов и дурных привычек
автоматизаторов, многих из которых они даже не
стыдятся! Тьфу, ироды окаянные!
Мы также не будем заниматься классификацией, что
является смертным грехом, а что – так, мелкое
прегрешение. Просто покайтесь потом на всякий
пожарный.

3. ВОПРОС ИЗ ЗАЛА
Прокрастинация?
Да ну, бросьте, это и не грех никакой.

4. ТРИ КИТА БЫДЛОАВТОМАТИЗАТОРА

5. ТРИ КИТА БЫДЛОАВТОМАТИЗАТОРА
Иногда создается впечатление, что других языков программирования
человечество не придумало. 90% всех автоматизаторов планеты продолжают
наворачивать тесты на все тех же заскорузлых и всем давно устывших языках, а
кое-кто – еще и на каких-то древних версиях оных, про которые все остальные
забыли еще лет пять назад.
Что ими движет? Может быть, они крутые и состоявшиеся специалисты в Java и
.NET, которые знают свою область вдоль и поперек и которым просто нет резона
что-либо менять? Ага, как же.
«У нас приложение написано на этом языке», - оправдываются они. Да похуй, на
чем оно написано; можно подумать, у них где-то напрямую вызывается его код.
Или может, кто-то рассчитывает, что к написанию тестов подключатся
разработчики?
Наложили в штаны? Вот это больше похоже на правду.

6. СОВОК БЫДЛОАВТОМАТИЗАТОРА
Среди автоматизаторов хватает людей,
считающих себя прогрессивными и
современными. Они искренне не понимают,
почему до сих пор живут в условиях командно-
административной системы и презрительно
называют сторонников прежнего политического
и экономического уклада «совками».
Друзья, так вы сами – точно такие же совки.
Вам точно так же стремно и в падлу выходить из
зоны комфорта, и вы готовы ковыряться в
какой-нибудь безнадежно замшелой шестой
джаве до тех пор, пока вас насильно не
заставят переключиться на что-то иное. Да
притом ладно бы что качественное писали...
Не кивайте на разработчиков. Разработчикам
диктуют стек технологий требования заказчика.
Вы вольны определять его сами.

7. СОВОК ЗДОРОВОГО ЧЕЛОВЕКА
Вот, что скажет вам Капитан Хаос. Не существует ни одной чисто технической причины
использовать такое архаичное и многословное говно как жаба или сишарп для написания
автотестов. Если у вас на проекте они все же используются, то:
• либо вы ничего другого не знаете и слишком тупы и ленивы, чтобы освоить что-то новое,
• либо вас никто и не спрашивал, и все было выбрано за вас.
И то и другое – плохо. Избавьтесь, наконец, от коротких штанишек и начните жить полной
жизнью!

8. ХОЗЯЙКЕ НА ЗАМЕТКУ
Целочисленное умножение на 1000 от крутого и состоявшегося Java-специалиста.
Пример из жизни.
Integer.parseInt(new Integer(42).toString() + "000");
Легко видеть, что от перемены языка он менее хуевым не становится. Вместе с
тем, обратите внимание, насколько более лаконичным стал даже этот говнокод:
read $ show(42) ++ "000" :: Int
(42.toString + "000").toInt
(42.to_s + ‘000’).to_i
Да, некоторым от коротких штанишек лучше не избавляться. Если под ними такое...
Впрочем, мы же собирались обойтись без скабрезностей.

9. ПЕЙДЖ-ОБДЖЕКТЫ И СТРАНИЦЫ
Как проиллюстрировать превращение разумной
идеи в абсурд? Дать недалекому автоматизатору
спроектировать пейдж-обджект.
Не все автоматизаторы знают, что паттерн Page
Object назван в честь гитариста Led Zeppelin и не
имеет никакого отношения к понятию «страницы».
«Сказано – страница, значит, и у меня, блядь, будет
страница», - решает рядовой автоматизатор,
вхуяривая очередной класс на несколько сотен
строк и впихивая в него и хедер с футером, и
менюшки с бредкрамбами, и весь-превесь контент,
какой только ни пожелал отобразить единовременно
в приложении перебравший накануне абсента
бизнес-аналитик или UX-дизайнер, рисовавший
мокапы.

10. ПЕЙДЖ-ОБДЖЕКТЫ И НАСЛЕДОВАНИЕ
Особо продвинутые (как им кажется) автоматизаторы создают
базовый класс с названием наподобие Generic- или BasePage,
куда сгружаются все общие куски и откуда потом наследуются все
конкретные классы страниц.
Ну еще бы, ведь если занимаешься главным образом
автоматизацией UI, иного случая блеснуть своими познаниями в
механизмах ООП может и не представиться. Иначе же это просто
какие-то структуры на стероидах, а вовсе никакие не классы!

11. ПЕЙДЖ-ОБДЖЕКТЫ И НАЛИЧИЕ МОЗГА
Между тем, принцип единственной обязанности никто не отменял. Если
ваш класс умеет заполнять и сабмитить форму, переходить по ссылкам
в меню, да еще и логаутиться из приложения, то вы явно его не
соблюдали.
Почему бы не сделать вместо одного класса три? Надо вам логаут –
вызвали соответствующий метод соответствующего класса. Между
прочим, большинство этих вспомогательных классов с практической
точки зрения – синглтон-объекты, так что их даже инстанциировать по
сто раз ни к чему.
Хотя зря я это сказал. Сейчас все кинутся клепать повсюду паттерн «синглтон»...
«Но... мы же не сможем возвращать из методов пейдж-обджект при
редиректе», - слышатся робкие возражения. А и хуй с ним! Все равно
эта модель работает только в простейших случаях и трещит по швам,
если тип вновь загружаемой страницы зависит от введенных данных,
роли пользователя или фазы луны.

12. ОБЕРТКИ ОТ КОНФЕТ И ДЫРКИ ОТ БУБЛИКОВ
Автоматизаторов хлебом не корми – дай написать
какую-нибудь обертку или «враппер», как они их
называют.
К примеру, особым шиком считается наворотить
абстрактный интерфейс для двух разных реализаций
Селениума (скажем, RC и WebDriver) с тем, чтобы
«можно было переключаться с одного на другой,
ведь это гибкость, красота и вообще». Ну конечно,
больше-то поупражняться в наследовании и
полиморфизме негде.
Известен случай, когда подобная модель была
создана из-за того, что «вебдрайвер не может
кликнуть по кнопке в одном из наших приложений».
Как оказалось, ребята кликали не по тому элементу.

13. ГИБКОСТЬ И САМООБМАН
Главным аргументом в пользу такого рода систем является:
«Мы потенциально сможем поддерживать любой тул, не
обязательно даже Селениум».
Чуваки, если у вас поменяется тул для автоматизации, вам так или
иначе придется переписать 90% вашего фреймворка. Смойте эту
вашу гибкость в толчок и решайте задачи по мере их поступления.

14. КОВАРНЫЙ АРХИТЕКТУРИТ
Это – лишь один из примеров запущенного архитектурита.
Архитектурит (лат. architecturitis) – опасное и малоизученное заболевание, с
трудом поддающееся лечению. Различают проактивную и реактивную формы
архитектурита, хотя некоторые исследователи считают их просто двумя
симптомами одного заболевания.
Проявления болезни сводятся к восприятию своего тестового кода как
коробочного продукта, который продается клиентам наряду с собственно
тестируемым приложением, и число пользователей которого уж никак не
меньше нескольких десятков тысяч, что приводит к необходимости особых
архитектурных решений, повышающих «конфигурируемость», «гибкость» и
«масштабируемость» системы.
Архитектурит традиционно считается постыдным заболеванием, в котором
больные ни за что добровольно не признаются (а зачастую даже не осознают
самого факта болезни). Таким образом, архитектурит находится в одном ряду с
такими недугами как геморрой, гонорея, хламидиоз и обгрызание заусенцев.
Тьфу, я же обещал без скабрезностей!

15. КОВАРНЫЙ АРХИТЕКТУРИТ
Пациенты, страдающие проактивной формой заболевания,
склонны предаваться мегаломаниакальным настроениям в
отношении архитектуры разрабатываемого ими фреймворка.
Горячечный бред и вспышки немотивированной агрессии
чередуются с попытками втиснуть в тестовый код как можно
больше слоев абстракции и IoC-контейнеров – как правило,
безотносительно их практической уместности.
Больного легко распознать по частому употреблению им слов и
фраз «гибко», «расширяемо», «обратная совместимость», «внешняя
конфигурация», «если вдруг все поменяется» и т. п.

16. КОВАРНЫЙ АРХИТЕКТУРИТ
Реактивная форма проявляется менее ярко и в некоторых случаях проходит
самопроизвольно. Типичный больной реактивным архитектуритом весьма
остро реагирует на предложения изменить интерфейсы или сигнатуры каких-
либо компонентов фреймворка, мотивируя это тем, что «это же сколько
придется рефакторить». Решение он видит во внедрении дополнительного слоя
абстракции или какой-нибудь хитрой логики ветвления с тем, чтобы старый код
продолжал работать по-старому.
Как легко заметить, само по себе такое поведение выглядит достаточно
разумно и еще не свидетельствует о наличии заболевания. Диагноз, однако,
легко подтверждается посредством анализа клиентского кода и обнаружения
всего одного или двух вхождений злосчастного метода или класса, которые
даже вручную рефакторятся в течение пяти минут.

17. ВРАППЕРИЗМ КАК ОН ЕСТЬ
Другая излюбленная тема «оберточников»
- написание так называемых
«декораторов» для UI-элементов.
«Декораторы» в среде автоматизаторов
стали столь же обязательным
аксессуаром, как треники, кепка-уточка
или сидение на кортах у гопников. Если
вы никогда не хуячили «декораторы», то
вы и не нормальный отвечающий
автоматизатор вовсе, а так, шпана
залетная, жизни не нюхавшая.

18. ВРАППЕРИЗМ КАК ОН ЕСТЬ
Из проекта в проект кочует этот, порядком уже подзаебавший, набор
«оберток» для кнопок, линков, текстбоксов и прочей лабуды. Все они,
разумеется, наследуются от какой-нибудь «суперобертки» под названием,
скажем, BaseUIElement (заметили? еще один способ поупражняться в
наследовании).
Причина популярности «декораторов», по всей видимости, кроется в
стремлении все на свете запихнуть в прокрустово ложе класса. Встречаются
даже классы без полей или методов: иначе мозг автоматизатора, очевидно,
отказывается воспринимать соответствующие сущности:
public class Label extends BaseUIElement {}
Ну и что такого уж плохого в оберточничестве? А что плохого, если ваш сосед
постоянно шмыгает носом или прочищает горло? Да ничего, просто обрыдло.

19. ВРАППЕРИЗМ КАК ОН ЕСТЬ
Многие декораторы ограничиваются тем, что оборачивают какой-нибудь
один вызов метода нижележащего API и не делают больше ничего
предосудительного. Помимо захламления системы вреда от них никакого
нет.
К несчастью, не всегда все складывается столь радужно. Иногда автор
считает нужным включить в декоратор перед собственно операцией над
элементом какую-нибудь проверку, а то и не одну. В сочетании с
паттерном «Сон» это может приводить к сокрушительным последствиям.
Особенно этим почему-то любят грешить наши недалекие коллеги из
далекого Хайдарабада. Впрочем, не рассчитывайте, что вас минет чаша
сия потому лишь, что вы меньше загорели!

20. КАК ОСЧАСТЛИВИТЬ ЧЕЛОВЕЧЕСТВО
Каким же будет следующий шаг нашего
оберточника-энтузиаста, этого Данко, этого
Прометея автоматизации?
Разумеется, помочь ближнему!
«Я спасу вас, люди!» - кричит охваченный
воодушевлением врапперист, выкладывая на
гитхабе очередной «проектонезависимый»
фреймворк, безмерно облегчающий
написание автотестов и делающий этот
процесс не более сложным, нежели лузгание
семок у подъезда.
Как я уже говорил, у оберточников и
шантрапы из подворотни есть что-то общее.

21. КАК ОСЧАСТЛИВИТЬ ЧЕЛОВЕЧЕСТВО
Что же представляет собой этот новый мегафреймворк, без которого
автоматизаторы долгие годы блуждали в потемках, натыкаясь на дверные
косяки и ножки кроватей?
Базовых вариаций две. Это:
• либо слегка переработанное API от Селениума с добавлением таких
жизненно важных фич как декораторы UI-элементов,
• либо еще один тул из серии «Автоматизация для двоечников», в
котором можно писать тестовые сценарии, не умея программировать,
а в особо запущенных случаях – даже составлять их из каких-нибудь
кубиков и ромбиков в графическом редакторе.

22. КАК ОСЧАСТЛИВИТЬ ЧЕЛОВЕЧЕСТВО
Пожалуй, ни один инструмент автоматизации тестирования не обрастал таким
количеством оберток как Селениум. Безграмотность и безалаберность
авторов оригинального Вебдрайвера, так и не сумевших спроектировать
более-менее юзабельное API, которое бы не требовало постоянных
обвраппериваний, просто поражает!
Как насчет того, чтобы при думать что-то свое? Сколько можно заворачивать
этот несчастный Вебдрайвер во все новые и новые слои однообразной
шелухи? Ну а уж если эта шелуха вам по каким-то причинам приятна и решает
какие-то ваши проблемы, с чего вы взяли, что она будет полезна кому-то еще?
Да и потом, к чему лишать других удовольствия накошмарить свой
собственный набор оберток, которые они, по крайней мере, смогут сами
допиливать под собственные нужды (а не сражаться с вашей обезображенной
архитектуритом архитектурой)? Мы, знаете ли, тоже умеем генерить
однообразную шелуху, но предпочитаем подписывать ее своим именем!

23. КАК ОСЧАСТЛИВИТЬ ЧЕЛОВЕЧЕСТВО
Про программирование без
программирования я уж и говорить не
хочу.
Почему-то никто не пытается генерить
программы из вордовского файла с
юзер-стори или техзаданием. Схуяли
вдруг это окажется практичным для
автотестов? Тест – точно такая же
программа, только
специализированная, и доверять его
разработку людям, не умеющим этого
делать, по меньшей мере неразумно.
Долой BDD и BDSM! Даешь лютый и
бескомпромиссный программный кот!

24. ФРЕЙМВОРКОПИСЦЫ И ХИМИЯ
Несколько озадачивающим трендом является популярность названий
фреймворков и тулов, заканчивающихся на «-иум». Типа, с закосом под
химию, ага.
Что интересно, большинство их авторов если и не получали в школе по
химии исключительно тройбаны, то уж по окончании ее забыли все это
как страшный сон, и теперь не смогут даже сказать, сколько валентных
изомеров у бензола.
Нет, я тоже этого не знаю. Но я-то под химика и не кошу.

25. ФРЕЙМВОРКОПИСЦЫ И ХИМИЯ
Ладно Селениум, тогда это еще не стало модным. Теллуриум – что ж, по крайней мере,
остроумно.
(Вы вот, кстати, в курсе, что как селен, так и теллур, довольно токсичны? От избытка селена, между прочим, у животных наблюдается
потеря шерсти и деформация копыт. Хотите, чтобы у вас выпадала шерсть и деформировались копыта? Лично я нет, чего и вам
желаю. Почему было не выбрать что-нибудь не столь ядреное – скажем, Кислородиум или Чугуниум?)
Но потом все словно с цепи сорвались. Роботиум. Ксебиум. ФлексОбезьяниум. Аппиум
(который, кстати, если разобраться, тоже Обезьяниум). Фитниум. ФлюентЛениум (вы
ебанулись там вообще?). Лишь один выскочка додумался обозвать свой фреймворк
Селенидом, но большой популярности этот тренд не получил.
Не все сумели вовремя сориентироваться в ситуации. Одна девица окрестила свое
детище Протрактором – теперь, небось, локти кусает, что не назвала его Нодиумом или
Ангуляриумом.
Ручаюсь, популярность соответствующих инструментов и библиотек была бы куда выше,
будь они поэтично названы Фукидидиум и ХТМЛЭлементиум. Видите ли, автоматизаторы
почему-то удивительно падки на все, что каким-либо образом связано с химией. Если
они видят название на «-иум», в них сразу просыпается жгучее желание куда-нибудь это
внедрить.

26. ДМИТРИЙ ИВАНОВИЧ НЕ ОДОБРЯЕ
Может,
хватит уже?

27. ВПЕРЕД, В БЕСКОНЕЧНОСТЬ!
Что же ожидает нас в будущем? Немного помечтаем и представим себе
такие тестовые фреймворки как Автоматиум, Тестиум и Антибагиум,
Йцукиум, Въебиум (что? есть уже такой? ах ты ж блин!) и Цианиум, а также Унылиум,
Бездарниум и, быть может, даже Никакоговоображениум.
А дальше?
Какая сфера науки сменит химию на пьедестале автоматизации?
Математика? Астрономия? Анатомия? Как насчет фреймворка
«Шрёдингер», в котором тест не является ни зеленым, ни красным до тех
пор, пока его кто-нибудь не проанализирует? Или инструмента под
названием «Нога»?
Почему «Нога»? Потому что fuck you, that’s why!

28. DIVIDE ET IMPERA
«Что бы еще замутить эдакого, архитектурненького», - размышляет иногда
автоматизатор, закончив писать оберточки и декораторчики. И тут его
осеняет: вот оно! Надо непременно что-то сделать с локаторами. Самое
лучшее – вынести куда-нибудь во внешнее хранилище (в качестве
какового обыкновенно выступает эксель-файл).
На хера? «Теперь можно будет подправлять локаторы, не меняя кода», -
гордо заявляет он, показывая вам спредшит о двух колонках и
нескольких тысячах строк, в каждой из которых некая, хочется надеяться,
уникальная, константа ставится в соответствие километровому xpath’у.
Те, кто посноровистее, объявляют в дополнение на стороне кода
здоровенный enum или класс-контейнер со всеми этими же константами
– чтобы, значится, строки не передавать туда-сюда. Логично, чо.

29. DIVIDE ET IMPERA
Создается впечатление, будто автотесты будут распространяться в
скомпилированном виде, а правкой локаторов будут заниматься всякие
необученные и далекие от программирования люди – это, по крайней
мере, хоть как-то оправдало бы отделение локаторов от кода.
Смех да и только! В подавляющем большинстве случаев автотесты лежат
себе под контролем версий в виде исходников и компилируются уже на
месте, непосредственно перед исполнением. Так какая же, блядь, вам
разница, какой из файлов редактировать, если уж это так необходимо?
Истинная причина, разумеется, не в практических соображениях, а все в
том же старом добром архитектурите. Если не устроить внешнее
хранилище (и не написать пару сотен строк обвязки, которая данные
оттуда вычитывает), то могут подумать, что вы не умеете проектировать
сложные системы. А этого допускать нельзя!

30. А ЭТО ИЗЮМ. НО ОН НЕ ПРОДАЕТСЯ.
Но и это еще не все.
Выстроив многоэтажную иерархию
классов и настрочив врапперков,
автоматизатор решает, что надо бы еще
что-нибудь во что-нибудь завернуть.
И тут ему на глаза попадается такой
ключевой элемент тестовых фреймворков
как ассерт.
Завидя в тестовом методе голый и ничем
не прикрытый ассерт, автоматизатор
заливается краской и отводит глаза в
сторону. Это непотребство обязательно
нужно куда-то спрятать!

31. НЕТ АССЕРТНОЙ ОБНАЖЕНКЕ!
Так на свет появляются многочисленные методы со словом «verify» в
названии. Внутри они, как правило, не содержат ничего, кроме все того же
ассерта.
Впрочем, верифаями дело иногда не ограничивается. Почему бы не хуйнуть
ассерт в каком-нибудь методе бизнес- или даже UI-слоя? Главное ведь –
чтобы его никто не увидел в неглиже на уровне тестов!
Тем самым все слои автоматизационного проекта оказываются привязаны
к используемому тестовому фреймворку или библиотеке ассертов. Ну да, это
не так уж страшно: ведь фреймворки, в конце концов, не меняют как
перчатки.
Это примерно как пойти и насрать на лестничной площадке пятого этажа,
оправдавшись тем, что вы там все равно никогда не появляетесь, так как
живете на третьем.

32. ТЕПЕРЬ НАС НЕ ОСТАНОВИТЬ
Неуемное рвение настоящего автоматизатора автоматизировать все мало-
мальски автоматизируемое – неугасимо! Начальство его в этом только
поощряет. В самом деле, для начальства цифры типа 85% или 67.3%
выглядят неубедительно. «А почему не 100%?» - вопрошает начальство. – «А
ну, подать мне 100%!»
Речь, если кто не понял, о покрытии тест-кейсов. Если у автоматизатора
затуманен либо отсутствует мозг, его под зажигательные речи начальства
охватывает энтузиазм и кипучая жажда деятельности. Он готов
автоматизировать проверку всего подряд, начиная от цвета шрифтов и
заканчивая выгрузкой файлов через UI.
Ай все, что-то эта презентация мне надоела. Давайте я не буду
аргументировать, почему это плохо, а вы просто поверите на слово, что так
делать не надо. 100%-покрытие – миф, и автоматизировать некоторые вещи
просто потому, что вы это можете, - неразумно.

33. ПОКАЙТЕСЬ!
Теперь то вы видите, что все вы – грешники, и за
свои отвратительные и богопротивные злодеяния
будете гореть в Автоматизационном Аду?
Ну или не будете.
Мне-то откуда знать, в конце концов.
Так или иначе, идите и не грешите более.

34. ВОПРОСЫ?
=)