Николай Алименков - Паттерны проектирования в автоматизации тестирования
HTML-код
- Опубликовано: 3 окт 2017
- Ближайшая конференция - Heisenbug 2024 Autumn, 10 октября (Online), 17-18 октября, Санкт-Петербург
- Ближайшая конференция: Heisenbug 2023 Autumn - 10-11 октября (online), 15-16 октября (offline)
Подробности и билеты: bit.ly/3qd3swV
- - -
. . .Паттерны проектирования известны в разработке уже много лет. Одни разработчики любят их, другие считают бесполезными. Но у паттернов проектирования есть очень чёткие задачи: описания типичные решения для типичных проблем, создать общий язык для сообщества, улучшить понимание и переиспользование существующих подходов.
У автоматизации тестирования есть свой собственный набор задач, так что существует и набор полезных паттернов проектирования для этой области. В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.
Спасибо, все супер!
Хороший доклад, спасибо!
По паттерну стратегия чет не вьезжаю
ruclips.net/video/EnooA2kEhY0/видео.html
В данном примере как вызывать нужную реализацию?
вот допустим мне надо регистрировать пользователей с разными типами регистрации:
-полная
-быстрая
-упрощенная
я делаю интерфейс с методом register и 3 класса, по одному для каждого типа. И как потом их вызывать? Дайте пример
суперполезный доклад классного разработчика !
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
Супер
По делу с 3:40
Просмотрено
осталось только поискать простые примеры применения паттернов, у нас внедряли кукумбер, каждый шажок в системе отображался в фиче, сотни шагов в фиче, малейшее изменение в системе и будешь всю это махину перелопачивать, слать надо таких манагеров с этим кукумбером
Потому что он сейчас внедряется ради внедрения, а не потому что реально нужен
Интересны паттерны не только в Селениум но и в Cypress... Такие штуки в сайпресе не подходят, там другой подход
8:30 #1 Page object
@ слушать дальше
В рай без очереди.
Интересный и очень полезный доклад, спасибо
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... Там как раз про разницу легко и просто