Телеграмм чат группы js_for_testing страница 3296

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

JS for testing

1414 membersпожаловаться на группу

2020 June 08

M

Marina in JS for testing

Alexander Popov

Че будешь делать если захочешь на инпут кликнуть?

пока не сталкивалась с такой потребностью. Но всегда есть возможность добавить

selectors: {
   tapableInput: {
       i: "tFieldSelector"
   }
}

+ не-типовые элементы также присутствуют, но тогда просто не прогоняются через этот метод и описываются просто в selectors, без доп. вложенности

источник

13:43пожаловаться #1

OI

Oleksii Ihnatiuk in JS for testing

ООП подход мне больше нравится, чем такая порнуха с вложенностью объектов

источник

13:49пожаловаться #2

OI

Oleksii Ihnatiuk in JS for testing

Зачем усложнять представление селекторов, если их не выносить на уровень теста

источник

13:51пожаловаться #3

OI

Oleksii Ihnatiuk in JS for testing

Найти нужный селектор будет ещё та забава в полотне вложенных объектов. ничего сложного, но приятного мало

источник

13:51пожаловаться #4

OI

Oleksii Ihnatiuk in JS for testing

Делаешь классы с типовыми элементами и при инициализации передаешь селектор и что ещё надо. В пейдже инициализируешь прям в том методе, где будешь использовать.

источник

13:53пожаловаться #5

AP

Alexander Popov in JS for testing

пока не сталкивалась с такой потребностью. Но всегда есть возможность добавить

selectors: {
   tapableInput: {
       i: "tFieldSelector"
   }
}

+ не-типовые элементы также присутствуют, но тогда просто не прогоняются через этот метод и описываются просто в selectors, без доп. вложенности

Значит будет два селектора одинаковых в двух местах для одного элемента?

источник

14:42пожаловаться #6

M

Marina in JS for testing

Alexander Popov

Значит будет два селектора одинаковых в двух местах для одного элемента?

да, похоже на то)
(но - действительно - просто не сталкивалась)

источник

14:44пожаловаться #7

AP

Alexander Popov in JS for testing

да, похоже на то)
(но - действительно - просто не сталкивалась)

Ну это вроде не красиво, м? А что если надо проверить текст, который может быть в хедере, в ссылке, в таблице, на кнопке, в инпуте?

источник

14:45пожаловаться #8

AP

Alexander Popov in JS for testing

Мне это чем то напоминает библиотеку из джавы, где пробовали элементы типизировать...

источник

14:46пожаловаться #9

AP

Alexander Popov in JS for testing

А в чем профит такого подхода, с одним методом?

источник

14:46пожаловаться #10

M

Marina in JS for testing

Alexander Popov

Ну это вроде не красиво, м? А что если надо проверить текст, который может быть в хедере, в ссылке, в таблице, на кнопке, в инпуте?

не красиво, да.
справедливости ради - если где-то есть текст - то он, как правило, текст. И даже на кнопке - есть кнопка, а есть текст кнопки и у них свои разные селекторы) но да, нестыковки видны

источник

14:48пожаловаться #11

AP

Alexander Popov in JS for testing

не красиво, да.
справедливости ради - если где-то есть текст - то он, как правило, текст. И даже на кнопке - есть кнопка, а есть текст кнопки и у них свои разные селекторы) но да, нестыковки видны

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

источник

14:49пожаловаться #12

M

Marina in JS for testing

Alexander Popov

А в чем профит такого подхода, с одним методом?

речь не идёт об одном методе вообще. Речи идёт, грубо говоря о том, чтобы часто используемые методы все вынести и объединить.
природа обделила меня оперативной памятью и при создании новой пейджи, когда много новых действий, я как раз в "это элемент такой, у него такой тип, это такой метод, который из вот оттуда импортится" путаюсь. А когда сразу всё описано по типам - попроще таки, помнить не надо

источник

14:50пожаловаться #13

MB

Michael Bodnarchuk in JS for testing

Діма Потапов

Кто работал с codeceptjs и у него уже есть нормальное понимание как строить автоматизацию на нем, можно сделать livecoding, то что я попытался с ним сделать, мне показалось что он крайне не удобен и забагован

дык, давай созвонимся, может чем смогу помочь

источник

14:50пожаловаться #14

M

Marina in JS for testing

Alexander Popov

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

в смысле кусок локатора кнопки в объекте с локаторами текстов? о,о пока исходя из этого прихожу к выводу, что иначе должен быть объект кнопки, в котором лежит локатор текста для кнопки

источник

14:51пожаловаться #15

AP

Alexander Popov in JS for testing

речь не идёт об одном методе вообще. Речи идёт, грубо говоря о том, чтобы часто используемые методы все вынести и объединить.
природа обделила меня оперативной памятью и при создании новой пейджи, когда много новых действий, я как раз в "это элемент такой, у него такой тип, это такой метод, который из вот оттуда импортится" путаюсь. А когда сразу всё описано по типам - попроще таки, помнить не надо

Потому что есть пейджи, но они представляют собой структуру данных, а не объект... Если бы это была абстракция над страницей - у неё были бы понятные функции типа "headershouldhave(text)" - а как оно там проверяется не важно

источник

14:51пожаловаться #16

ДП

Діма Потапов... in JS for testing

Michael Bodnarchuk

дык, давай созвонимся, может чем смогу помочь

го)

источник

14:51пожаловаться #17

AP

Alexander Popov in JS for testing

в смысле кусок локатора кнопки в объекте с локаторами текстов? о,о пока исходя из этого прихожу к выводу, что иначе должен быть объект кнопки, в котором лежит локатор текста для кнопки

Смысл по как раз в создании абстракции которая будет прятать всякие локаторы, ассерты, клики и ховеры. И тогда после точки у тебя будет окошко с юзер-действиями в которых нельзя запутаться

источник

14:52пожаловаться #18

M

Marina in JS for testing

Alexander Popov

Смысл по как раз в создании абстракции которая будет прятать всякие локаторы, ассерты, клики и ховеры. И тогда после точки у тебя будет окошко с юзер-действиями в которых нельзя запутаться

да, но это на уровне описания теста.
я говорю именно о пейдже - селекторы (локаторы?) жеж именно на ней должны описываться?

источник

14:54пожаловаться #19

M

Marina in JS for testing

Alexander Popov

Потому что есть пейджи, но они представляют собой структуру данных, а не объект... Если бы это была абстракция над страницей - у неё были бы понятные функции типа "headershouldhave(text)" - а как оно там проверяется не важно

и, конечно, вопрос отвлечённый, но - почему структура данных не может быть объектом?)

источник

14:57пожаловаться #20