#automation #patterns

Давненько не писал ничего околотехнического, и сегодня про вопрос с собеседований "А какие паттерны знаешь"?

Что я думаю про PageObject и гордо звучащий PageFactory, про которые вспомнят 9 из 10 на этот вопрос?

Первое - это не "паттерн" в прямом смысле этого слова. В том смысле, что если мы будем делать ООП-программу про зоопарк, там будет обект "Жираф" с полями "private вес" и "private рост" и методами "поесть()" / "поспать()". Так же будет объект "Зебра" и объект "Вомбат". Можно ли сказать, что мы изобрели паттерн "ЗверьОбжект"? В нашей системе каждый зверек это объект. в котором есть свойства (поля) и методы, через которые мы взаимодействуем с ним.

Так вот, Web-тесты на Java (и другом любом ООП языке) - и есть программка про зоопарк (про веб-странички), и PageObject - это просто класс с полями и методами, описывающий предметную область. И если понимать это, то легко понять и точку зрения, например, Андрея Солнцева: "PageObject не всегда и не очень-то и нужен". Ровно в той же степени, как класс (объект) "Жираф" может быть не очень то и нужен, если в нашем зоопарке с ним не так уж и много взаимодействий. И если дизайн этого класса сделан плохо.

А PageFactory - это чтение аннотаций в классе, которому придумали нелепое название. Это не имеет никакого отношения к Factory - который, сам по себе, хороший паттерн и встречается часто.
А еще я встречал точку зрения, что если методы в PageObject возвращают ссылку this, то это PageFactory. Что тут сказать? Я не знаю откуда взялось мнение, что это так называется. В ООП у этого есть вполне конкретное название - Fluent interface.

Поэтому не надо на собеседовании говорить, что вы знаете паттерны PageObject и PageFactory.

На такой вопрос лучше ответить так:

Если вы меня спрашиваете про "паттерны тестировщиков" и хотите послушать про PageObject - я вам расскажу, но если вас интересует понимаю ли я, что такое Decorator, Singleton, Proxy, Factory (настоящую) - то сейчас я вам расскажу про них

.

И рассказать 🙂

Codefest #14 сегодня закончился.

Хочу рассказать про свою работу в программном комитете этой конференции (в котором я уже три года подряд).

Я точно не самый ответственный ПК-шник, особенно пару последних лет, когда перешёл в ДОДО и стал иногда сходить с ума от созвонов и дел на работе. Я вел мало докладчиков в этом году.

И все же, знаете, я испытываю гордость за те немногие доклады (их было всего три), к которым я действительно приложил руку. Я иногда сам себе кажусь "злым полицейским" на прогонах: увеличь текст! Слишком много текста! Слишком много кода! Слишком мало кода! С какой главной мыслью человек уйдет из зала?

Но после, я вижу как сами спикеры кайфуют на сцене от получившегося результата. Как люди увлеченно смотрят, слушают, записывают...

Мне уже почти 35, мне больше хочется радоваться за чужие доклады, а не за свои.

А ещё сегодня был лучший закрывающий keynote , который я видел в жизни.
Перформанс (нет, это было больше, чем доклад, именно - перформанс) от Александра Кирсанова, на котором люди были растроганы до слез в конце. До настоящих слез, а не просто ради красивой фразы.

Посмотрите его когда-нибудь после.

Об интересных багах, обнаруживаемых прямо в ресторане;

Есть у нас телевизоры, показывающие статус заказа. И есть возможность завести себе длинное имя в приложении - например, в честь советского журнала "Юный натуралист". И в результате имеем очень загадочного юного натурала...

Как бы вы предложили это пофиксить?
И какие еще можете придумать имена, которые будут забавно обрезаться по маске {12 символов}{3 точки}? 😁

#Менеджмент

Только что прочитал в одном из QA каналов, что главная проблема начинающих лидов (менеджеров) - делегирование. И это правда🥲 Но, есть еще одна - критически важная - вещь в менджерстве, о которой мало говорят.

Я ее называю "работа с сомнениями".

Например, вам кажется что с этой метрикой что-не то. Или что с этим товарищем что-то не то (не дорабатывает? или перерабатывает?). Или что с этим процессом что-то не то. Ключевой слово - вам кажется, вы не уверены до конца, что это так. И здесь хороший менеджер должен приложить все усилия, что бы погрузиться в это подозрительное место и изменить свое мнение либо в утвердительное - да, это плохо, надо брать и менять, либо наоборот - мне просто показалось, все работает хорошо, и больше не особо и думать об этом.

К сожалению, часто мы видим менеджеров которые чем-то недовольны, но не идут к решению проблемы. Почему? Потому что возникает необходимость принимать на себя риски и ответственность (кстати, понимание слова ответственность - повод для отдельного поста🙂).

На мой взгляд, при возникновении сомнений, надо обязательно с ними работать, что бы качнуть весы в ту или иную сторону. И, кстати, если меня просят на собесе вспомнить свои менеджерские фэйлы - почти все они связаны с тем, что я давал этим сомнениям "самим рассосаться".

Сомнения надо устранять.

16 ноября в Алматы будет крупный IT-event "от авторов и создателей" уже легендарного Сибирского Codefest. Я, как участник Программного комитета, жду ваши заявки по QA теме в нашем CFP. А на любые вопросы о конфе постараюсь ответить в треде.

Кружка за второе место в рейтинге зрительских симпатий СИБИРЬ JS...🥲 А первое место - и заслуженно - у Вадима Никитенко из Раййфа. Подписывайтесь, Вадим крутой: джавист, тайпскрипист и создатель крутых презентаций.

#patterns #automation

О неправильном понимании Принципа единственной ответственности (Single-responsibility principle) применительно к PageObject.

На днях один из моих студентов задал вопрос:

Добавили в РО вместе с остальными шагами. Насколько правильно шаги с ассертом объединять в одном РО?
Вот в РО на авторизацию. У меня есть и шаг заполнения полей с кликом и проверка результата. На работе настучали по рукам, чтобы проверка была не в РО, а именно в тесте

Казалось бы, простой вопрос с простым ответом🙂
И далее:

Я после своего вопроса решил сам исследовать проблему. В некоторых "умных книжках", сказали, что нельзя использовать ассерты. Так как разделяют на: "методы для взаимодействия с элементами страницы" и "методы для проверки состояния элементов страницы". Это, как я понимаю, ведет к нарушению принципа SOLID по единой ответственности и поэтому нельзя.

И вот тут я понял, что надо писать пост.

Всем мы на подсознательном или осознанном уровне понимаем, что такое Single responsibility. Это - максимально упрощая - когда класс UserController отвечает за создание и редактирование юзеров, и не отвечает за отправку e-mail-ов с прогнозом погоды.

На чем базируется это с технической точки зрения в ООП?

На инкапсулированных зависимостях UserController-а. Нет, я понимаю что все можно написать на static методах, но все-таки, UserController должен выглядеть примерно так:

class UserController {
   private final UserRepository userRepository;

и вот этот userRepository - он работает с юзерами в БД (я в курсе, что инжектить репозитории в контроллеры не надо, это просто пример).

Важно тут то, что наш UserController не должен инкапсулировать EmailWeatherNotifier, и чисто технически не должен получить возможность отвечать за что-то не то (нарушать S в слове SOLID).

А теперь к PageObject🙂:

class LoginPage {
   private final SelenideElement usernameInput = $("#username");
   private final SelenideElement passwordInput = $("#password");

Что он инкапсулирует? Элементы на странице. У этих элементов есть метод click(), setValue(...) и, внезапно, shouldBe(...).
Я не понимаю, как использование shouldBe(...) (ассерта) может являться здесь нарушением Single responsibility, а setValue(...) - нет.

И то, и другое - это работа со страницей авторизации. И это и есть одна ответственность класса LoginPage.

Пока в ваших PageObjecta-х инкапсулированы только элементы страницы, вы не нарушите никаких Solid-ов.

Добавляйте методы с ассертами и проверками в свои PageObject-ы на здоровье, если хотите - не добавляйте, создавайте AssertObject-ы, но во всех этих случаях - не слушайте псевдоумные рассуждения про SOLID применительно к данному случаю.

Думаю многие слышали про Spring initializr. Это когда вы можете не думать, какие там плагины, зависимости и т.д. вставить в свой pom.xml (ну или build.gradle), а в режиме "проставить галочки че хочу на выходе" получаете готовый Spring-проект.

К чему это я?

Хочу прорекламировать (бесплатно, конечно🥲) появление такой-же фичи в Allure!

И там-то она ну точно полезна - сколько людей путаются в версиях AspectJ и java, в плагинах и зависимостях Allure и прочем. Единственное, что бы я посоветовал доработать - в генерируемом build.gradle (pom.xml) добавлять exclude junit-а из
testImplementation "io.qameta.allure:allure-junit5"

Это полезно, потому что при использовании самых последних и свежих JUnit-ов могут возникнуть конфликты, т.к. аллюр может не успевать день-в-день за выходом нового релиза JUnit. Я бы подключал это так:

    testImplementation("io.qameta.allure:allure-junit5:${allureVersion}") {
        exclude group: "org.junit.jupiter"
    }

В общем, сохраняйте ссылку и пользуйтесь Allure start!

Сегодня и завтра я на главном событии года DODO - съезде партнеров. Тут все ключевые лидеры DODO, партнеры, открывшие кто пару, а кто и больше сотни наших ресторанов. Наша цель - Х2 во всем. И качество наших IT-продуктов - ключевая вещь, без которой ничего не будет. Весь первый день я слушал выступления наших топменеджеров, но в мыслях было - а как мы будем делать все это качественно и без багов? Эти мысли сложнее, чем написание тестов, тесткейсов и всего остального. Нам нужен прорыв, нам нужно избавиться от багов на оплате, нам нужно безупречное приложение и безупречная работа бэкофиса. Нам нужен крутой QA, который тоже будет х2 от конкурентов. Это все еще вызов для меня, хотя казалось бы, где еще искать вызовы, когда ты уже 16 лет во всем этом IT.

Тот самый лучший, на мой взгляд, Keynote, который я видел на айтишных конфах (а побывал я на многих). Посмотрите, прочувствуйте

Свежайший видос с HB от меня - опять JUnit, опять экстеншены

💪 Сегодня в 20:00 по МСК приглашаею на открытый урок: "Niffler 2.0".
Это созданный мной и Ириной Стяжкиной (бэк и фронт соответсвенно) учебный проект, в котором есть все, что есть у меня в голове. Хочу поговорить (не очень технически, скорее душевно) про:

✅ Эволюцию Niffler от первой версии до сегодняшнего дня. О чем мы думали, делая этот проект?

✅ О своем взгляде на учебный процесс для синьеров AQA

🔗 Зарегистрируйтесь на этот стрим и мы можем просто пообщаться в конце, на любые темы. А может быть, увидимся на моем авторском курсе, стартующем через 2 дня 😳 Скидка тут, если что

В конце сентября буду в Москве с докладом про GraphQL, а точнее, про то, как его автотестировать с точки зрения логики на бэке.

Буду рад пообщаться вживую, доклад стоит последним, после него - сплошное after-party 🍻

Всем, кто хотел со мной пообщаться лично в Питере, go завтра (26.09) на митап Ю.money, где я буду выступать со своим докладом о догмах тестирования