Николай Алименков - Паттерны проектирования в автоматизации тестирования
Вставка
- Опубліковано 3 жов 2017
- Ближайшая конференция - Heisenbug 2024 Autumn, 10 октября (Online), 17-18 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Tq0vcu
- Ближайшая конференция: Heisenbug 2023 Autumn - 10-11 октября (online), 15-16 октября (offline)
Подробности и билеты: bit.ly/3qd3swV
- - -
. . .Паттерны проектирования известны в разработке уже много лет. Одни разработчики любят их, другие считают бесполезными. Но у паттернов проектирования есть очень чёткие задачи: описания типичные решения для типичных проблем, создать общий язык для сообщества, улучшить понимание и переиспользование существующих подходов.
У автоматизации тестирования есть свой собственный набор задач, так что существует и набор полезных паттернов проектирования для этой области. В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.
Спасибо. Как жаль что я не встретил этот доклад раньше.
Спасибо, все супер!
8:30 #1 Page object
@ слушать дальше
В рай без очереди.
Супер
По паттерну стратегия чет не вьезжаю
ua-cam.com/video/EnooA2kEhY0/v-deo.html
В данном примере как вызывать нужную реализацию?
вот допустим мне надо регистрировать пользователей с разными типами регистрации:
-полная
-быстрая
-упрощенная
я делаю интерфейс с методом register и 3 класса, по одному для каждого типа. И как потом их вызывать? Дайте пример
суперполезный доклад классного разработчика !
По делу с 3:40
Est ktonibud kto uzhe mnogo let v Seleniume i mozet pomoch razobratsja s pravelnoi arhetekturoi? budu ochen blagodaren, i ewjo est gdenibud kod etoi prezintacii? mne interesno sto proishodit v abstraktnoi stranice
Просмотрено
осталось только поискать простые примеры применения паттернов, у нас внедряли кукумбер, каждый шажок в системе отображался в фиче, сотни шагов в фиче, малейшее изменение в системе и будешь всю это махину перелопачивать, слать надо таких манагеров с этим кукумбером
Потому что он сейчас внедряется ради внедрения, а не потому что реально нужен
В кукумбере тоже можно сделать сборные шаги, через ж но можно.
Cucumber ненавидят все автоматчики и никто в своем уме сам не будет юзать эту технологию. Огурец работает только если вся команда придерживается BDD подхода, и реально используют геркин тесты как живую документацию для всей команды. И даже в этом случае это жертва со стороны автоматизации, ради общего блага команды. И шаги в геркине должны быть прописаны в общем, без конкретных деталей. Бизнес логика без технических деталей. Когда же пишут геркин детально, да еще используют кукумбер только как тулу для автоматизации, то это убожество от которого надо убегать как можно быстрее, пока оно не похоронило тебя под собой.
Интересны паттерны не только в Селениум но и в Cypress... Такие штуки в сайпресе не подходят, там другой подход
Хороший доклад, спасибо!
Интересный и очень полезный доклад, спасибо
34:15 Насчет пула БД, у меня есть свой подход. Я делаю бинарные дампы (например, pg_basebackup для PostgreSQL), и когда надо с помощью rsync за 2 секунды накатываю нужный дамп на бд. Необходимость в пуле полностью отпадает.
Николай Алименков, а на слайде почему-то Михаил).
Спасибо за доклад, вы один из спикеров, которых очень интересно слушать.
Видно Вы не из Беларуси. Там написано Mikalai, что переводится как Николай =)
@@georgeatester верно, спасибо, буду знать :)
На высоте, Круто, Спасибо.
Зачастую Бизнесс не хочет участвовать в процессе тестирования - он хочет большую красную кнопку, которая будет делать хорошо. Только делать, жать и отчитываться о результатах её нажатия будет Исполнитель. А Бизнесс может максимум создать эффект контроля глубокого присутствия в том или ином процессе - потому что (как им кажется) так кнопка появится быстрее и будет делать ровно то, что должна.
Поэтому не усложняйте себе жизнь БДДшными подходами - они ни к чему.
Вы только подумайте - будет ли менеджер тратить время на то, чтобы перелопатить базу из N сотен тыстов, чтобы выяснить есть ли там та пара тестов, которые он хочет добавить? Или он просто как на вентилятор накинет в репу эти пару тестов (а потом еще и еще пару таких же тестов), которые продублируют аналогичные существуюшие? И кто потом будет эти дубли вычищать?
Полностью подтверждаю. На деле так обычно и получается, что в эту кучу bdd тестов не то, что менеджеры или бизнес, а даже ручные тестировщики с трудом залезают. Не говоря уже о том, чтобы их писать. А всё потому, что в реальных условиях это не будет выглядеть, как вписать 2, вписать 5, получить в сумме 7.
Начало 3:40 Много лишних слов. "Почему я это хочу делать, а хочу делать я это потому что" и приличная часть доклада из подобных слов, т.е. можно запросто сократить все слова раза в 2 - 3 без потери смысла. И будет больше уважения к времени слушателей.
Пионэр вожатый
сам все делаю с помощью паттерна steps и больше ничего не надо мусор. проф уровень у этого парня
Я бы предплоложил, что дело в проектах, с которыми ты имел дело работать, если простых захаркоженых шагов было всегда достаточно. Не более, не менее..
@@ildarvalitov2568 Я бы предположил, что бывают у людей разные типы восприятия. Мы всегда опираемся, что, к примеру, лучше всё выписать в абстракции некие. Чтобы выглядело небольшим и красивым. Вот только почему-то в паттернах автотестов никто не опирается на то, что у людей бывает совершенно разный тип восприятия.
Пример: человеку проще пройтись глазами по 100 тестовым классам. И найти нужный, и в нём что-то сделать. Чем смотреть, что нагенерила фабрика. Просто у него такой склад ума к примеру. Что он просто выглядящие, но огромные массивы данных обрабатывает куда быстрее.
Так же и тут, предположу, что человеку нафиг не сдались те же пейж обжекты. Ему легче большой тест от начала до конца промотать глазами, и он так гораздо быстрее поймёт логику, нежели, если бы он заморачивался с описанием пейжей.
В этих паттернах и принципах всё завязано на какой-то условный "более правильный подход". Но вот о психике и восприятии людей ни слова.
Я также склоняюсь еще к тому, что мы все боимся на самом деле признать, что можно сделать всегда очень просто.
Но в таком случае за что нам платят такое бабло. Примерно так.
И да, я сейчас сказал то, что запрещено наверное говорить. Пойти устроить конференции и обесценить всех автотестеров))
@100 100 позвольте с вами не согласиться в части "кому-то проще прочесть большой тест со всеми кишками от начала до конца".скорее всего если абстракции созданы хорошо, то под них не надо проваливаться чтобы понять их суть... Как пример - ведь врядли этот же человек каждый раз проваливается вглубь матчеров, чтобы понять суть проверки. Например тут:
assertThat(newLinkedHashSet("Luke", "Yoda")).have(jediPower); assertThat(newLinkedHashSet("Leia", "Solo")).doNotHave(jediPower);
Я понял что основная проблема что понятную абстракцию сформировать не всегда легко - в и этом все дело...
Есть доклад создателя кложуры (даже есть с русскими субтитрами) Simple Made Easy... Там как раз про разницу легко и просто