кто-то подскжает проксю рабочую США-шную? фришную, желательно

tunnerBear, ZenMate

это впн же. прокси это например плагин для хрома frigate.

Эй, там ищут людей из билайна, у меня тоже вопрос к ним, фигли инет такой не стабильный?(((

+1 в гусях инета почти нет

Закрутил так закрутил, этот паттерн просто описывает логическую часть страницы, всё остальное притянуто за уши

Видимо, читая один и тот же текст, мы с вами видимо разное. Я вижу вполне понятную декларацию разделения логики тестов от логики объектов. Вынесение локаторов в отдельный уровень - и правда немного другая история, больше про UI Mapping, но в рамках Page Object тоже отлично поддерживается.

Кто-нибудь работал плотно с Windows Performance Recorder?.. последнее время больше Assesment toolkit гоняла, а тут появилась необходимость провести ряд тестов под WPR, и я внезапно столкнулась с тем, что по каким-то причинам в ETW попадают только последние события перед save-ом (например, шла построчная запись в файл, 100 итераций по 1000 строк), и в WPA вижу адекватное время "жизни" процесса, но дисковая активность, прохождение через минифильтры и т.п. - только для последних "2.5" итераций. Я так понимаю, что применяется профиль для transient performance issues, но вообще все настройки соответствуют прекомендациям для "ustained performance issues".

кстати, как вам следующая модель автоматизации тестирования веба - автоматизатор подготавливает платформу, автотесты пишет ручной тестировщик. Автоматизатор подготавливает инфраструктуру (фреймворк, виртуалки, логирование). Причем во фреймворке нет инициализации объектов, зато есть таблица в базе и интерфейс для добавления объектов (jquery синтаксис, например) Ручной тестировщик учит jquery и для написания автотеста сам добавляет нужный ему объект в базу. тем самым момент актуализации при изменении путей в dom-дереве лежат не на автоматизаторе, а на ручном тестере

кстати, как вам следующая модель автоматизации тестирования веба - автоматизатор подготавливает платформу, автотесты пишет ручной тестировщик. Автоматизатор подготавливает инфраструктуру (фреймворк, виртуалки, логирование). Причем во фреймворке нет инициализации объектов, зато есть таблица в базе и интерфейс для добавления объектов (jquery синтаксис, например) Ручной тестировщик учит jquery и для написания автотеста сам добавляет нужный ему объект в базу. тем самым момент актуализации при изменении путей в dom-дереве лежат не на автоматизаторе, а на ручном тестере

Звучит отвратительно. Почти как BDD.

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

То есть в данном случае xpath лучше чем jquery

Ну, лучше всего - тестовые айдишники, потому что перемещение элемента по дому их не ломает.

Но да, xpath лучше jquery, потому что не требует велосипедов.

вы там видел Fluent Page Object ? ( https://youtu.be/jT1mIQmdVuo?t=25m6s )

Интересный видосик? Стоит посмотреть?

Интересный видосик? Стоит посмотреть?

я б посоветовал, сам не досмотрел, но очень хочется

У нас как раз сейчас в проекте непонятки, как работать с PageObject и что туда стоит засовывать

если я правильно пониммаю, то jquery как представитель css? а xpath ему противопоставляется на основании чего? xpath требует постоянного перестроения при длинной нотации, если у тебя элемент в элементе не ищется. У меня была необходимость починить чужие тесты с xpath - так вот там надо было из 10 /div/div/div.../div поставить порядковый номер одному из дивов, что это за див и где его найти - никаких идей :) хоть что-то сместил - и абсолютно другой объект находтися. в этом случае id либо data-test (или как угодно назвать можно) атрибут к элементу, что бы изменения DOM не сказывалось на остальных элементах, а при короткой длине особой разницы нет.

Звучит отвратительно. Почти как BDD.

чем BDD не угодил?

если я правильно пониммаю, то jquery как представитель css? а xpath ему противопоставляется на основании чего? xpath требует постоянного перестроения при длинной нотации, если у тебя элемент в элементе не ищется. У меня была необходимость починить чужие тесты с xpath - так вот там надо было из 10 /div/div/div.../div поставить порядковый номер одному из дивов, что это за див и где его найти - никаких идей :) хоть что-то сместил - и абсолютно другой объект находтися. в этом случае id либо data-test (или как угодно назвать можно) атрибут к элементу, что бы изменения DOM не сказывалось на остальных элементах, а при короткой длине особой разницы нет.

вот как раз такие xpath отвритетельны, поддерживать такое - адовый ад

чем BDD не угодил?

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

ну, я просто попытался предположить чем xpath крут, а jquery ацтой. костыли есть везде

так ведь в этом случае тесты становятся приятны и понятны всем заинтересованным лицам, которые умеют читать (я про BDD).

оверхед на инженеринг есть везде, поддержка - тоже

так ведь в этом случае тесты становятся приятны и понятны всем заинтересованным лицам, которые умеют читать (я про BDD).

А кому, кроме QA и разработчиков, они должны быть понятны?

PO и заказчикам как тестовая документация

если она нужна

Если нужна тестовая документация - пишите тестовую документацию.

БДД тесты таковой всё равно не являются.

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

не сказал бы, что их сложно поддерживать, зато у тестов крутая читаемость и понятное поведение, никакой магии для внешнего человека) и еще становится приятнее писать тест на реальный юзкейс по БДД, чем по xUnit'у условному

А кому, кроме QA и разработчиков, они должны быть понятны?

разработчику другой команды, который пишет на другом языке, например)

не сказал бы, что их сложно поддерживать, зато у тестов крутая читаемость и понятное поведение, никакой магии для внешнего человека) и еще становится приятнее писать тест на реальный юзкейс по БДД, чем по xUnit'у условному

Вы всегда пишете реальный тест под реальный юзкейс. Вы или пишете код, или пишете псевдокод. Псевдокод - лишняя депенденси, которую надо поддерживать.

Вы всегда пишете реальный тест под реальный юзкейс. Вы или пишете код, или пишете псевдокод. Псевдокод - лишняя депенденси, которую надо поддерживать.

Дайте угадаю, вы на джаве пишете? :)

Нет, я пишу на пайтоне, сейчас пересаживаюсь на рубя. На джаве тоже писал. Но к чему вопрос?

ну просто я такие аргументы слышу исключительно от тех, кто пишет/писал на джаве)

разработчику другой команды, который пишет на другом языке, например)

Даже человек без опыта программирования вообще за вечер-два может неспешно разобраться в синтаксисе автотестов. Благо логика там примитивнее некуда.

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

Если вы пишете нечитаемый код - БДД вас не спасёт. Если вы пишете нормальный читаемый код - полезность от БДД есть только условным менеджерам, которым это ненадо читать.

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

Ещё раз, у вас фронтендер не может разобраться в коде тестов? Вы там, простите, логику коллизий в тесте описываете, или что?

Ещё раз, у вас фронтендер не может разобраться в коде тестов? Вы там, простите, логику коллизий в тесте описываете, или что?

может)

Тогда вы пишите в тестах то, чего не надо писать в тестах. Thats all folks.

Тогда вы пишите в тестах то, чего не надо писать в тестах. Thats all folks.

окей, пусть будет так)

Ну, т.е. тесты сами по себе - предельно простая по логике вещь. У вас есть прекондишен, вынесенный в отдельный кусок кода а-ля Setup, у вас есть Action и есть Assert.

Самая сложная часть всего этого - прекондишен.

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

Ну, т.е. тесты сами по себе - предельно простая по логике вещь. У вас есть прекондишен, вынесенный в отдельный кусок кода а-ля Setup, у вас есть Action и есть Assert.

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

Причем тут селекторы, собственно?

Валидный тест это всегда precondition -> action -> assert.

а, ну я не так прочитал) по логике простая, да

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

вопрос в том, что делать если у вас 5 прекондишенов

и в разных тестах они разные

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

Ну, так может имеет смысл учиться писать автотесты, а не обвязками обмазываться?

тогда уже не так и просто :)

PageObject не нужен, обвязками наобмазывались

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

да вы писать не умеете

а я дартаньян

PageObject не нужен, обвязками наобмазывались

Пейдж обжект - не обвязка, это паттерн.

БДД - обвязка, потому что вводит дополнительный уровень абстракции.

Грубо говоря, фреймворк.

БДД - обвязка, потому что вводит дополнительный уровень абстракции.

тогда пайтест тоже обвязка?)

тоже вводит фикстурки, удобные прекондишены

bdd грубо говоря тоже фреймворк

давайте без них будем жить в питоне, unittest с сетап-теардаун и поехали

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

и геттеры с сеттерами писать в питоне будем заодно

ERROR: S client not available

а я к тому, что я не очень различил нелюбовь к однму и любовь к другому

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

примерчик в студию

Затрудняюсь сказать, юзаю пайтест исключительно для генерации отчетов.

С Селениумом наглядный пример - подмена запросов\ответов.

С Селениумом наглядный пример - подмена запросов\ответов.

раскройте мысль, не очень понял, если честно. проблема в том, что ее там нет?

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

Встал господин Баранцев в позу, что "Мы про юзер-лайк тестирование" и всё, что обёрнуто в запрос селениума ты не достанешь никак.

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

Ещё раз, Пейдж обжект про то, как структурировать код. Он не вводит дополнительных библиотек, зависимостей и прочего. Это паттерн.

Бдд - это фреймворк.

Встал господин Баранцев в позу, что "Мы про юзер-лайк тестирование" и всё, что обёрнуто в запрос селениума ты не достанешь никак.

ну он прав, нет? селениум и делали для user-like тестирования)

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

ну он прав, нет? селениум и делали для user-like тестирования)

Прав или нет - понятие относительное. Это их право делать свой фреймворк так, как они считают нужным. Проблема в том, что если для 90% тестов их "видение" фреймворка совпадает с моими задачами, а для 10% - нет, то фреймворк мне не подходит.

Потому что приходится сидеть и втыкать костыли.

а что вы используете в питоне и в рубях? на чем тесты бегают?

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

Вот использование любой сторонней библиотеки - это такого рода риски. С БДД, за счёт черезвычайно высокого уровня абстракции, этих рисков больше (ибо каждый уровень абстракции это +1 место где что-то может пойти не так).

просто как бы на западном рынке Ruby это синоним Cucumber+Watir, и топовые чуваки юзают Ruby потому что BDD там роднее некуда

У нас TDD тесты пишутся через RSpec и вот это всё.

Автотесты - на капибаре.

эээ

Ещё раз, Пейдж обжект про то, как структурировать код. Он не вводит дополнительных библиотек, зависимостей и прочего. Это паттерн.

Уровень абстракции — один из способов сокрытия деталей реализации определенного набора функциональных возможностей. Применяется для управления сложностью проектируемой системы при декомпозиции, когда система представляется в виде иерархии уровней абстракции. давайте определим "Уровень абстракции" как сказано выше. В каком виде PageObject не создаёт уровень абстракции? Сокрывает как именно и с какими элементами он взаимодействует для выполненеия конкретного действия, так?

Под руби много классных продуктов, ватир и кукумбер лишь одни из.

TDD на уровне функциональных тестов?

Под руби много классных продуктов, ватир и кукумбер лишь одни из.

я привел пример, язык и экосистема очень хороши

куча всего классного, это правда

Нет, ТДД на уровне юнитов. Там Рспек. На уровне функциональных - капибара и никакого бдд.

регулярки из коробки ван лав)

Нет, ТДД на уровне юнитов. Там Рспек. На уровне функциональных - капибара и никакого бдд.

то есть вы юзаете BDD обертку для TDD без BDD?

я верно понял?

точнее на юнитах бдд конечно не нужно

но почему тогда рспек