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

Ещё раз. БДД есть на уровне юнитов. Потому что это документация кода. Именно фактической его работы. Помогает при ревью и входе в проект. Ну, и просто потому, что разработчики выбрали комфортный им инструмент и решили юзать. Колются но жрут.

На уровне функциональных тестов bdd нет, bdd оберток тоже нет.

Просто потому, что там и не надо.

интересно)

а что, по тдд реально удобно работать?

на более-менее сложных задачах?

Ну, у нас биллинг, процессинг и вот это всё. Им норм. :)

это понятно) но все равно непонятно, почему bdd абстракция на низком уровне есть, а на высоком ее быть не может

у вас разработчики разве код читать не умеют?)

это понятно) но все равно непонятно, почему bdd абстракция на низком уровне есть, а на высоком ее быть не может

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

Проблемов с чтением тестов на капибаре у них, AFAIK, не возникает. :)

в общем, я не хочу говорить об абстракции более. слишком абстрактное понятие

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

вынести локаторы отдельно это не пейдж обджект так то

хоть ты и не мне реплаил

то есть от факта группировки у тебя паттерна реализованного не появляется

то есть от факта группировки у тебя паттерна реализованного не появляется

Пейдж обжект - это про вынесение логики страницы в класс страницы, т.е. вдаль от логики самого теста. Вынесение локаторов это немного отдельная история, да. Уровень взаимодействия с объектами от этого не меняется, меняется только роутинг.

PageObject? А что с ним не так?)

Тут люди БДД с ПейджОбжектом сравнивают.

да тут спор, добавляет PageObject абстракции или нет

Пейдж обжект - это про вынесение логики страницы в класс страницы, т.е. вдаль от логики самого теста. Вынесение локаторов это немного отдельная история, да. Уровень взаимодействия с объектами от этого не меняется, меняется только роутинг.

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

и в рамках этого сравниваем BDD vs PageObject - кто больше абстракции и необходимой поддержки

но если ты вынес локаторы из тестов в другой файл - это абстракция если ты вынес ещё и методы по работе с этими локаторами в ещё один файл - то это ещё один уровень и так далее, или я не прав?

PageObject , это вы в каком средстве с ним работаете?

ну так то ты можешь навернуть пейдж обджект в BDD, так что у тебя там будет комбобрейкер

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

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

тогда каким образом БДД это дополнительный уровень абстракции? в питоне все реализации БДД это просто декораторы над функциями

ну это один уровень абстракции, я согласен. но на него ты не повлияешь.

Йеп. И вот эти декораторы, между твоей логикой теста, и тем что делается под капотом - это ещё одна обвязка.

у тебя вместо бдд может быть питест/юниттест/что угодно

Т.е. так у тебя есть: логика теста -> методы тестового фрейморка -> вебдрайвер. В случае бдд у тебя есть: логика теста -> логика псевдонатурального языка -> методы тестового фреймворка -> вебдрайвер.

thats it.

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

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

Для них выключено логирование, например.

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

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

Тебе надо их мейнтейнить.

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

И если что-то идет не так - тебе надо это дебажить.

и типо все норм и никто не жалуется)

И если что-то идет не так - тебе надо это дебажить.

ты дебажишь метод

Ага, или криво написанный декоратор для этого метода.

Ага, или криво написанный декоратор для этого метода.

окей, а еще что там может быть?

тогда каким образом БДД это дополнительный уровень абстракции? в питоне все реализации БДД это просто декораторы над функциями

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

Всмысле "что ещё?" Я уже описал, у тебя, по сути, есть цепочка из 4 уровней взаимодействия. На каждом уровне взаимодействия что-то может пойти не так.

Всмысле "что ещё?" Я уже описал, у тебя, по сути, есть цепочка из 4 уровней взаимодействия. На каждом уровне взаимодействия что-то может пойти не так.

я про то, что опечатка может быть на любом уровне абстракции

а что еще может пойти не так с декоратором самим?

Да, и чем таких больше - тем больше надо дебажить.

Большинство людей, которые активно выступают за бдд, сами не пользовались такими инструментами. Ну или пользовались, но писали только код на этом псевдоязыке

Да, и чем таких больше - тем больше надо дебажить.

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

Большинство людей, которые активно выступают за бдд, сами не пользовались такими инструментами. Ну или пользовались, но писали только код на этом псевдоязыке

я пишу полный цикл на бдд и люблю бдд) и на небдд тоже пишу

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

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

А профит довольно сомнителен при этом.

Для них выключено логирование, например.

как то оно отдельно по приложениям не включается

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

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

как то оно отдельно по приложениям не включается

Ну, вообще на стороне приложения включается. Т.е. приложение может сказать "не логируй меня".

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

Конечно, в фреймворках нет багов и они не накладывают ограничений на код, который под них пишется.

Думаю если вы правда в это верите, то дискуссию можно закрыть.

Конечно, в фреймворках нет багов и они не накладывают ограничений на код, который под них пишется.

конечно есть, но я вот не встречал

я пишу полный цикл на бдд и люблю бдд) и на небдд тоже пишу

А можете привести пример наиболее типичного у вас теста? Какие там шаги и что проверяется?

А я встречал.

Ну, вообще на стороне приложения включается. Т.е. приложение может сказать "не логируй меня".

ну на виртуальных машинах все логируется, а с физического ни один процесс выбрать нельзя http://i.imgur.com/cTAZfDA.jpg

А можете привести пример наиболее типичного у вас теста? Какие там шаги и что проверяется?

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

А я встречал.

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

я встречал баги в кор либе в питоне, что ж теперь, мне на С переходить? :) (отредачено, в питоне пока не находил)

Ну то есть тест проверяет что-то типа "в такое-то поле вводим такое-то значение, нажимаем на кнопку, -> на странице в таком-то поле выводится такое-то другое значение"?

я встречал баги в кор либе в питоне, что ж теперь, мне на С переходить? :) (отредачено, в питоне пока не находил)

абсолютли

Ну то есть тест проверяет что-то типа "в такое-то поле вводим такое-то значение, нажимаем на кнопку, -> на странице в таком-то поле выводится такое-то другое значение"?

как вариант

ERROR: S client not available

я встречал баги в кор либе в питоне, что ж теперь, мне на С переходить? :) (отредачено, в питоне пока не находил)

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

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

у меня есть 2 позитивных опыта внедрения из двух) xUnit в рамках питеста тоже не могу назвать плохим)

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

Звучит как предложение написать бдд фреймворк с нуля.

Примерно как интерпритатор питона.

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

Ну, выше был пример с селениумом. Перехватить request\response, дополнить body нужным контентом, прокинуть дальше на клиент. Но это всё детали. Рассчитывать, что вы не упретесь в ограничения фреймворка - довольно самонадеянное занятие. У них цель - сделать базовые вещи, ваша цель - сделать вполне конкретные.

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

кстати, как решили такую задачу с перехватом request/response? проксей какой-то?)

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

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

Благо там это был довольно изолированный кусок тестов, где этот костыль мог жить и не мешать остальным.

а зачем вообще так делать?

то есть какая реальная задача, что надо именно на уровне селениума править ответ?

то есть какая реальная задача, что надо именно на уровне селениума править ответ?

изоляция апи от фронта. Полезно в случае кучи 3rd party сервисов в проекте. Более быстрые тесты фронта.

изоляция апи от фронта. Полезно в случае кучи 3rd party сервисов в проекте. Более быстрые тесты фронта.

так а селениум тут причем? почему нельзя отдавать фронту мокнутые ответы с бэка?

Можно.

В тесте можно сказать какой мок использовать

Самообеспечение опять же

не все бекенды доступны для внесения изменений в них

а чего бы не замокать со стороны фронта? Аля конфижек, который говорит, что на тестовой штуке не стучить в 3дПарти, а бери данные вот здесь и забудь, что он есть.

не все бекенды доступны для внесения изменений в них

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

она тебе всегда отдаст определенный ответ. или в зависимости от запроса ответ, или в зависимости от урла ответ)

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

а чего бы не замокать со стороны фронта? Аля конфижек, который говорит, что на тестовой штуке не стучить в 3дПарти, а бери данные вот здесь и забудь, что он есть.

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

Мокать хорошо работает когда тебе нужно получить полностью искусственный респонз

Когда тебе надо модифицировать только конкретный кусок - неочень

ну так замокайте все внешние на всех сразу, мы же один раз настраиваете тестовый контур. или это "ни в жизнь не обращусь за помощью к этим надменным разработчикам?"))

Мокать хорошо работает когда тебе нужно получить полностью искусственный респонз

да, это и была задача как раз

ну так замокайте все внешние на всех сразу, мы же один раз настраиваете тестовый контур. или это "ни в жизнь не обращусь за помощью к этим надменным разработчикам?"))

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

костылями и подпорками :)

костылями и подпорками :)

https://github.com/oesmith/puffing-billy https://github.com/vcr/vcr неплохие репы то, для костылей и подпорок

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