По паттерну стратегия чет не вьезжаю th-cam.com/video/EnooA2kEhY0/w-d-xo.html В данном примере как вызывать нужную реализацию? вот допустим мне надо регистрировать пользователей с разными типами регистрации: -полная -быстрая -упрощенная я делаю интерфейс с методом register и 3 класса, по одному для каждого типа. И как потом их вызывать? Дайте пример
34:15 Насчет пула БД, у меня есть свой подход. Я делаю бинарные дампы (например, pg_basebackup для PostgreSQL), и когда надо с помощью rsync за 2 секунды накатываю нужный дамп на бд. Необходимость в пуле полностью отпадает.
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 подхода, и реально используют геркин тесты как живую документацию для всей команды. И даже в этом случае это жертва со стороны автоматизации, ради общего блага команды. И шаги в геркине должны быть прописаны в общем, без конкретных деталей. Бизнес логика без технических деталей. Когда же пишут геркин детально, да еще используют кукумбер только как тулу для автоматизации, то это убожество от которого надо убегать как можно быстрее, пока оно не похоронило тебя под собой.
Зачастую Бизнесс не хочет участвовать в процессе тестирования - он хочет большую красную кнопку, которая будет делать хорошо. Только делать, жать и отчитываться о результатах её нажатия будет Исполнитель. А Бизнесс может максимум создать эффект контроля глубокого присутствия в том или ином процессе - потому что (как им кажется) так кнопка появится быстрее и будет делать ровно то, что должна. Поэтому не усложняйте себе жизнь БДДшными подходами - они ни к чему. Вы только подумайте - будет ли менеджер тратить время на то, чтобы перелопатить базу из N сотен тыстов, чтобы выяснить есть ли там та пара тестов, которые он хочет добавить? Или он просто как на вентилятор накинет в репу эти пару тестов (а потом еще и еще пару таких же тестов), которые продублируют аналогичные существуюшие? И кто потом будет эти дубли вычищать?
Полностью подтверждаю. На деле так обычно и получается, что в эту кучу bdd тестов не то, что менеджеры или бизнес, а даже ручные тестировщики с трудом залезают. Не говоря уже о том, чтобы их писать. А всё потому, что в реальных условиях это не будет выглядеть, как вписать 2, вписать 5, получить в сумме 7.
Начало 3:40 Много лишних слов. "Почему я это хочу делать, а хочу делать я это потому что" и приличная часть доклада из подобных слов, т.е. можно запросто сократить все слова раза в 2 - 3 без потери смысла. И будет больше уважения к времени слушателей.
@@ildarvalitov2568 Я бы предположил, что бывают у людей разные типы восприятия. Мы всегда опираемся, что, к примеру, лучше всё выписать в абстракции некие. Чтобы выглядело небольшим и красивым. Вот только почему-то в паттернах автотестов никто не опирается на то, что у людей бывает совершенно разный тип восприятия. Пример: человеку проще пройтись глазами по 100 тестовым классам. И найти нужный, и в нём что-то сделать. Чем смотреть, что нагенерила фабрика. Просто у него такой склад ума к примеру. Что он просто выглядящие, но огромные массивы данных обрабатывает куда быстрее. Так же и тут, предположу, что человеку нафиг не сдались те же пейж обжекты. Ему легче большой тест от начала до конца промотать глазами, и он так гораздо быстрее поймёт логику, нежели, если бы он заморачивался с описанием пейжей. В этих паттернах и принципах всё завязано на какой-то условный "более правильный подход". Но вот о психике и восприятии людей ни слова. Я также склоняюсь еще к тому, что мы все боимся на самом деле признать, что можно сделать всегда очень просто. Но в таком случае за что нам платят такое бабло. Примерно так. И да, я сейчас сказал то, что запрещено наверное говорить. Пойти устроить конференции и обесценить всех автотестеров))
@100 100 позвольте с вами не согласиться в части "кому-то проще прочесть большой тест со всеми кишками от начала до конца".скорее всего если абстракции созданы хорошо, то под них не надо проваливаться чтобы понять их суть... Как пример - ведь врядли этот же человек каждый раз проваливается вглубь матчеров, чтобы понять суть проверки. Например тут: assertThat(newLinkedHashSet("Luke", "Yoda")).have(jediPower); assertThat(newLinkedHashSet("Leia", "Solo")).doNotHave(jediPower); Я понял что основная проблема что понятную абстракцию сформировать не всегда легко - в и этом все дело... Есть доклад создателя кложуры (даже есть с русскими субтитрами) Simple Made Easy... Там как раз про разницу легко и просто
Structural Pattenrs
1. Page Object
2. Fluent/Chain of invocations
3. Factory/Page Facrtory
4. Page Element/Composite
5. Loadable Component
6. Strategy
Data Patterns
7. Value Object
8. Builder
9. Assert Object/Matchers
10. Data Registry
11. Object Pool/Flyweight
13. Data provider
14. Decorator
15. Proxy
Business Involvement Patterns
16. Keyword Driven Testing
17. Behavior Specification
18. Steps
Было очень круто и интересно. Спасибо большое за видео
8:30 #1 Page object
@ слушать дальше
В рай без очереди.
Спасибо. Как жаль что я не встретил этот доклад раньше.
По паттерну стратегия чет не вьезжаю
th-cam.com/video/EnooA2kEhY0/w-d-xo.html
В данном примере как вызывать нужную реализацию?
вот допустим мне надо регистрировать пользователей с разными типами регистрации:
-полная
-быстрая
-упрощенная
я делаю интерфейс с методом register и 3 класса, по одному для каждого типа. И как потом их вызывать? Дайте пример
Интересный и очень полезный доклад, спасибо
По делу с 3:40
Спасибо, все супер!
34:15 Насчет пула БД, у меня есть свой подход. Я делаю бинарные дампы (например, pg_basebackup для PostgreSQL), и когда надо с помощью rsync за 2 секунды накатываю нужный дамп на бд. Необходимость в пуле полностью отпадает.
Хороший доклад, спасибо!
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
Николай Алименков, а на слайде почему-то Михаил).
Спасибо за доклад, вы один из спикеров, которых очень интересно слушать.
Видно Вы не из Беларуси. Там написано Mikalai, что переводится как Николай =)
@@georgeatester верно, спасибо, буду знать :)
осталось только поискать простые примеры применения паттернов, у нас внедряли кукумбер, каждый шажок в системе отображался в фиче, сотни шагов в фиче, малейшее изменение в системе и будешь всю это махину перелопачивать, слать надо таких манагеров с этим кукумбером
Потому что он сейчас внедряется ради внедрения, а не потому что реально нужен
В кукумбере тоже можно сделать сборные шаги, через ж но можно.
Cucumber ненавидят все автоматчики и никто в своем уме сам не будет юзать эту технологию. Огурец работает только если вся команда придерживается BDD подхода, и реально используют геркин тесты как живую документацию для всей команды. И даже в этом случае это жертва со стороны автоматизации, ради общего блага команды. И шаги в геркине должны быть прописаны в общем, без конкретных деталей. Бизнес логика без технических деталей. Когда же пишут геркин детально, да еще используют кукумбер только как тулу для автоматизации, то это убожество от которого надо убегать как можно быстрее, пока оно не похоронило тебя под собой.
суперполезный доклад классного разработчика !
Супер
Зачастую Бизнесс не хочет участвовать в процессе тестирования - он хочет большую красную кнопку, которая будет делать хорошо. Только делать, жать и отчитываться о результатах её нажатия будет Исполнитель. А Бизнесс может максимум создать эффект контроля глубокого присутствия в том или ином процессе - потому что (как им кажется) так кнопка появится быстрее и будет делать ровно то, что должна.
Поэтому не усложняйте себе жизнь БДДшными подходами - они ни к чему.
Вы только подумайте - будет ли менеджер тратить время на то, чтобы перелопатить базу из N сотен тыстов, чтобы выяснить есть ли там та пара тестов, которые он хочет добавить? Или он просто как на вентилятор накинет в репу эти пару тестов (а потом еще и еще пару таких же тестов), которые продублируют аналогичные существуюшие? И кто потом будет эти дубли вычищать?
Полностью подтверждаю. На деле так обычно и получается, что в эту кучу bdd тестов не то, что менеджеры или бизнес, а даже ручные тестировщики с трудом залезают. Не говоря уже о том, чтобы их писать. А всё потому, что в реальных условиях это не будет выглядеть, как вписать 2, вписать 5, получить в сумме 7.
Просмотрено
На высоте, Круто, Спасибо.
Интересны паттерны не только в Селениум но и в Cypress... Такие штуки в сайпресе не подходят, там другой подход
Начало 3:40 Много лишних слов. "Почему я это хочу делать, а хочу делать я это потому что" и приличная часть доклада из подобных слов, т.е. можно запросто сократить все слова раза в 2 - 3 без потери смысла. И будет больше уважения к времени слушателей.
Пионэр вожатый
сам все делаю с помощью паттерна steps и больше ничего не надо мусор. проф уровень у этого парня
Я бы предплоложил, что дело в проектах, с которыми ты имел дело работать, если простых захаркоженых шагов было всегда достаточно. Не более, не менее..
@@ildarvalitov2568 Я бы предположил, что бывают у людей разные типы восприятия. Мы всегда опираемся, что, к примеру, лучше всё выписать в абстракции некие. Чтобы выглядело небольшим и красивым. Вот только почему-то в паттернах автотестов никто не опирается на то, что у людей бывает совершенно разный тип восприятия.
Пример: человеку проще пройтись глазами по 100 тестовым классам. И найти нужный, и в нём что-то сделать. Чем смотреть, что нагенерила фабрика. Просто у него такой склад ума к примеру. Что он просто выглядящие, но огромные массивы данных обрабатывает куда быстрее.
Так же и тут, предположу, что человеку нафиг не сдались те же пейж обжекты. Ему легче большой тест от начала до конца промотать глазами, и он так гораздо быстрее поймёт логику, нежели, если бы он заморачивался с описанием пейжей.
В этих паттернах и принципах всё завязано на какой-то условный "более правильный подход". Но вот о психике и восприятии людей ни слова.
Я также склоняюсь еще к тому, что мы все боимся на самом деле признать, что можно сделать всегда очень просто.
Но в таком случае за что нам платят такое бабло. Примерно так.
И да, я сейчас сказал то, что запрещено наверное говорить. Пойти устроить конференции и обесценить всех автотестеров))
@100 100 позвольте с вами не согласиться в части "кому-то проще прочесть большой тест со всеми кишками от начала до конца".скорее всего если абстракции созданы хорошо, то под них не надо проваливаться чтобы понять их суть... Как пример - ведь врядли этот же человек каждый раз проваливается вглубь матчеров, чтобы понять суть проверки. Например тут:
assertThat(newLinkedHashSet("Luke", "Yoda")).have(jediPower); assertThat(newLinkedHashSet("Leia", "Solo")).doNotHave(jediPower);
Я понял что основная проблема что понятную абстракцию сформировать не всегда легко - в и этом все дело...
Есть доклад создателя кложуры (даже есть с русскими субтитрами) Simple Made Easy... Там как раз про разницу легко и просто