Для этого полезно еще понимать, как фича вообще работает(описание) заведенные баги, и известное поведение фичи из прошлых релизов

Доступность всего этого барахла по одному клику сильно бы сократило время на анализ... Вот и изучаю, какие попытки делаются в этом направлении.

Удачи :) лучше откусывать от задачи по чуть чуть

Сразу ничего не будет

Привет есть кто не спит и шарит в линухе?

Привет есть кто не спит и шарит в линухе?

И тебе не хворать, а чего надо?

Привет, может кто подскажет как подцепить конфигурацию свою для sbt плагина gatling?

Коллеги, такой вопрос: какой канонический вид у проекта для тестирования селениума? как должны быть раскиданы page object и элементы с локаторами по папкам проекта? а сами тесты?

нет канонического вида

пейджи - к пейджам, тесты - к тестам. локаторы можно хранить в каждом классе\ выносить в отдельный файл. Хелпер методы - в отдельную папку. конфиги, если их больше двух - в отдельную папку, если их 2 или меньше - можно в корне проекта держать. никакой магии и рокетсайенса. Для тестов нужно умудриться сделать сложной конвенцию проекта.

О, прекрасно! Благодарю. А почему локаторы не кладут внутрь пейджей? пейджы же на них ссылаются

кто "кладут"? это я не кладу. Потому что команде было удобнее в одном файле держать все локаторы

разработчики тестов

пейджи ссылаются на эти локаторы и имеют доступ только к тем, которые примешаны миксином в класс + если есть наследование от базовой страницы - еще локаторы базовой страницы

как уже говорилось, это частично Separation of Concerns, плюс мне нет никакого интереса коллапсить 20 локаторов пейджи на класс, каждый раз когда я с ним работаю, это бесполезные 20 строк в коде, в шапке класса, которые нужно прокручивать

Спасибо за объяснение)

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

сравни вид пейджи раз

и два

Почему во втором пейдже не был вызван метод инит у базового класса?

потому что я могу

кто мне запретит? :)

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

что вы понимаете под элементами?

и на каком языке вы хотите писать

PyTest

это не язык, но да ладно

элементы - конкретные элементы веб-страницы, имеющие свой локатор

ну да, я сразу решил написать, что на пайтесте, а не каком-то другом пакете

короче, нет никакого смысла иметь объекты как элементы веб страницы, забудьте об этом

в Питоне это не нужно, как не нужно для работы с react'ивщиной

но они так хорошо у меня лежат)

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

что вам дает элемент? какое-то состояние

зачем оно вам? я не знаю.

с реакт-домом, виртуальным или физически модифицируемым селениуму нужно брать и опрашивать на момент существования нужное ему состояние

нафига делать персистентность в элементах - я не придумал

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

наследоваться от него и прочее

есть состояние вебдрайвера, get_element и get_elements который как-то находит мне нужные элементы в методах. Все :)

Немного продолжая тему тестирования на селениуме. Может кто развернуть человеческим языком, что означают эти минусы при разработке автотестов на Nigthwatch.js?

нет, найтватч неочень

только асинк авейт для синхронизации асинхронного кода

чейнинг промисов не очень

Асинк авэйт глотает эксепшоны)

Хотя в тестах пох конечно)

В найтвотче нет чейнинга промизов в простом применении там вместо авэйтов экспектейшны с таймаутом

Почти линейно

Вопрос был про "человеческим языком"

А про ответ пояснить можешь?

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

ERROR: S client not available

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

Товарищи, подкиньте материалов по нагрузочному и тестировании безопасности

Пожалуйста

Я вернулся. :) У меня вопрос, вот у нас в России любят для автотестов ui selenium или какой-нибудь фреймворк на его основе. У меня новый работодатель и, внезапно, узнал, что тесты ui могут выполнятся с помощью capybara. Я еще недостачтоно погрузился в тему, но с первого взгляда тесты ui, выполненные не в браузере - это не совсем хорошая практика. Я прав?

И второй вопрос, есть кто работает на западе? Какие там бестпрактис по тестированию ui?

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

и использовать и селениум драйвер и капибара вебкит

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

Это я понимаю. Вопрос-то в том, хорошая это практика или нет?

Что именно хорошая практика? Вызывать браузерные тесты вместе с остальными из капибары?

Если да, то вполне нормальная. Вопрос только в том, как вы делаете сами тесты, а не на каком дсл вы их пишите и как запускаете

Плохая практика - инициализировать end to end тесты изнутри проекта, используя сущности которые не генерируются извне. И то, этот подход иногда тоже оправдан.

Плохая практика - инициализировать end to end тесты изнутри проекта, используя сущности которые не генерируются извне. И то, этот подход иногда тоже оправдан.

Не уверен, что понял тебя. Точнее совсе не понял, что тут имеется ввиду.

Ну, в чем разница между условными юнитами/integration и end to end с точки зрения тестовых сущностей? В юните ты просто инициализируешь новый экземпляр контроллера, например, и проверяешь корректность его работы.

Это понятно.

используя сущности которые не генерируются извне - вот, что меня смутило

End to end не работает напрямую с контроллером, он работает с той системой, в которой он содержится, и только на том уровне, на котором это доступно извне.

Соотв. Капибара на уровне end to end тестов так же гнать тесты на уровне систем, а не на уровне синтетически инициализированных кусков продукта.

А в целом капибара - еще один тестовый фреймворк, почему бы не гнать ui тесты через него. Правда dsl ужаснейший, но это дело вкуса.

я так понял он спрашивает хорошая ли практика использовать headless браузер

и это тоже

гугл сделал полноценный хедлесс хром, почему бы и нет

Это я понимаю. Вопрос-то в том, хорошая это практика или нет?

Не хорошая

Капибаре вебкит и капибаре в связке с селеницме вебдрайвером или другим драйвером это утопия

Так как в сложно м проекте где есть например ангуляр и формы с анимацией нужно по разному обращаться у инпутам или Баттона,

И разница в том что капибаре видит одно

Один елемент, селениуме может его не видеть вообще, а капибаре например с фантомом вообще его не уувидит

Лучше всего для ui использовать тот инструмент который работает с домом везде одинаково на разных драйверах и это мне кажется лучше всего делает селениум