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

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

Повторюсь, всё описанное применимо только если оценённая выгода от внедрения ощутимо перевешивает оценённые затраты.

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

Либо внедрение описанных в докладе средств красивоотчётостроения, когда нам нужно только "да/нет", потому что у нас всего 3 теста.

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

Ок, смари:
Первая мысль там, что он предлагает оперировать не объектами странице, а бизнес действиями (ba). Например залогиниться(логин, пароль). И тогда получится достаточно атомарно, чтобы каждый объект на странице использовался бы только 1 раз, так что его можно просто описать текстом в ba.
Во-вторых к этому добавляется тестирование всего уровнем выше (модульное, компонентное), где ты уже протестировал компонент "календарь" и уверен, что он точно выбирает нужную дату (и нужный диапазон, если что) и в ui-тестировании ты его уже не тестируешь и знаешь что дата у тебя выбрана правильно.
Ну и последнее, что он затрагивает в этом плане - то что в ba селекторы могут выглядеть криво. И случается такое потому что тестировщики не могут поговорить с разработчиками и поставить нормальные селекторы (я так вообще за сайпрес-вей, где ты ищешь элементы по тексту, хоть это и не везде применимо).
+ выше был наброс про то что он не говорит как правильно использовать бдд: говорит - для однозначной передачи заданий от заказчика к исполнителю. То есть аналитик написал given-when-then, а разработчик/тестировщик перевёл это в тест. Вот так бдд может работать.

А заведение объектов в jvm занимает в разы меньше времени чем старт инстанса браузера и тот
Thread.sleep(1000); // TODO: remove this. Хз чё оно падает.

> Замечательный в рамках выбранной тематики, пусть и заголовок чистой воды clickbait.

Не согласен -- заголовок-то интересен больше тем кто знает кто такой Солнцев, особого кликбейта там нет. Мало ли кто что ненавидит.

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

Тоже нет (если люди ищут решений проблем, они могут много у кого проконсультироваться).

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

"Агент Малдер, мне нужны доказательства".

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

У Солнцева речь шла о проблемах таких как доверие заказчика к команде или самоутверждения/самодурства менеджера через красивые идеи/отчёты. Или, вариант, могут хотеть "как у людей", "просто потому что", не понимая зачем. Который раз я натыкаюсь на упомянутую Солнцевым проблему "с БДД всем будет проще писать тесты" (а оно и не обязательно так, и не всем нужно). Какие "процессы" могут это решить, и при чём тут ссылка на чеклисты? Чеклисты решают проблему "не забыть" или "сделать обязательно".

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

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

От своего реального опыта с БДД я бы посоветовал считать наоборот: чаще его заводят от хотелок обещалок взятых из маркетинга.

> По поводу ООП в тестировании - на мой взгляд это пересекается с вопросом об использовании Java. Выбирая парадигму и/или язык мы заставляем себя мыслить в его терминах и писать так как принято.

С одной стороны это справедливая постановка вопроса "языка как 'оптики' через которую мы формулируем проблемы для себя и других ", с другой, как я не так давно в другом чате аргументировал, сама Java отказалась от подхода "всё ООП" (лямбды), и вообще появляется всё больше статей о том что на разных языках можно писать в немножко разных парадигмах (сейчас мода на функциональную).

> Разумеется можно писать на джаве не так, но человек обычно берётся за то что ему привычно известно раньше, чем начинает искать альтернативы (молоток и гвозди или тесты и затратная дырявая реализация page object вместо описанной в докладе как более удачная инкапсулировання)

Если человеку рассказали только про PO, то да, но ему могли-то и этого не рассказать. PO рекламируют как один из подходов (де)композиции.

> Тесты как-никак это сценарий из пункта А в пункт Б никуда не сворачивая,

Не обязательно. Практический контрпример: "игрок казино должен иметь возможность выиграть (в эту игру) два раза так чтобы это отразилось на его балансе" (по мотивам продакшен бага).
Но в казино не только выигрывают, проигрыши надо пропускать пока не выиграешь два раза. Вот это может быть "сворачиванием", и это всё равно тест.

Вообще говоря, антитезису этого подхода, рассказу о том какие "длинные" и "хитрые", но важные проблемы не находят _принципиально_ "короткие и прямые" проверки я посвятил значительную часть своего доклада на COMAQA Minsk 2019. Знаменитой "пирамиде" тоже досталось ;) .

> Насчёт сужения возможных действий - всё зависит от конкретной ситуации, но стоит помнить, что поскольку сам сценарий составляется условно-разумным оператором (а в бдд - ещё и в человекочитаемом виде), лично я не вижу смысла тратить усилия на создание искусственных ограничений заранее, ведь как всегда бизнес-процесс может поменяться и ограничения могут стать неактуальны, придётся поддерживать ещё и их. А если ограничений нет, а тест некорректен - он просто упадёт при первом запуске и его исправят, если вдруг попытались выполнить операции в недопустимом порядке.

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

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

Я пытаюсь пользу от этой схемы понять вообще. Одна из "проблем людей" состоит в том, что выбрать 1 пункт/объект из 4 человеку легче чем из 8, уже не говоря из 16 и больше. "Единый список локаторов" — это наоборот, это расширение, а не сужение.

Когда я писал о процессах - я имел в виду постановку работы таким образом, чтобы уменьшить влияние человеческого фактора, в том числе самодурства. В качестве примера таких действий по уменьшению влияния людей, привёл чеклисты и колл-центры.
Потому что это известные примеры. Исходил из того, что если бы я привёл какую-то более специфичную ситуацию, сразу бы получил вопрос "а всем ли это надо и у всех ли это сработает?", но и здесь, Роман, вы нашли как ударить по иллюстрирующему примеру, а не сути аргумента.

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

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

Если немножко в таком стиле ответить: какие ваши доказательства, что процессы "в текущем изводе чаще создают проблему и порождают тот самый репорт портал"? Всегда ли? Везде ли? Точно ли всем думать лень?

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

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

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


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

Уточню на всякий случай позицию: согласны ли вы с утверждением, что "хорошо", "правильно" работающий БДД подход в сумме с другими нужными для этого изменениями, способен в определенных условиях (опустим пока набор этих условий, они зависят от конкретного проекта) улучшать процесс разработки/тестирования больше, чем затраты на реализацию БДД? Если вы считаете, что БДД никогда не может окупиться, то нет смысла продолжать эту ветвь дискуссии и лучше переключиться на техническую составляющую.


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

Мой вопрос заключается в том, можем ли мы оценить, что проще, следить за веяниями в облегчении "тяжеловесной" джавы, или выбрать для проекта JS или Python как альтернативы. Опять-таки, не везде это рационально или вообще возможно, но при старте нового проекта стоит задаваться таким вопросом, а не сразу брать джаву, разве нет?

Насчёт примера с казино - он вполне укладывается в концепцию из А в Б, просто сам путь будет длиннее, чем просто 2 победы подряд. Я говорил о детерминированности сценария, например если мы автоматизируем этот сценарий - имеет смысл выбрать заранее количество промежуточных поражений. Иначе, получив зелёный тест мы даже не сможем быть уверены, что проверили именно ту ситуацию, которая до этого провела к ошибке, вдруг это были две победы подряд?

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


По поводу сужения - да, если набор возможных в каждой ситуации действий огромен, может быть смысл в автоматизации коридора допустимых действий. Но далеко не на всех проектах есть такая вариативность операций, тут можно перейти к вопросам схемы "локаторы хранятся в одном месте" - для некоторых проектов не стоит задача автоматизации тестирования через UI полной комбинаторики. Допустим, определено что необходимо автоматизировать 10-15 сценариев в наборе smoke тестов, а остальное проверять более быстро на низких уровнях.

Тогда возможна ситуация, в которой хранение локаторов оправдано. Ведь сайты сейчас строятся в том числе на компонентных подходах, составляются из различных виджетов и блоков, можно описать в PO отдельные блоки, а не страницы, если блоков много. А если блоков и задействованных элементов относительно мало - можно описать их в понятном участникам виде в одном списке.
Скажем, универсальные кнопки "далее", "отмена", 5-10 полей для ввода ФИО и номеров заявок и несколько проверочных неинтерактивных элементов, которые должны быть readonly и выдавать какие-то вычисления, которые мы проверяем.
В такой ситуации человеку под силу окинуть список взглядом, и при этом набора компонентов может быть достаточно для реализации выбранных smoke сценариев.
В таком подходе сами сценарии-то тестовые человек должен заранее представлять в голове или иметь документированное описание, до написания конкретного кода. Такой вариант работы "придумали тесты, потом закодили тесты" вряд ли же можно назвать особенно экзотическим.

я один скипаю эти полотна ?

не дорос еще до серьезных бесед

как и я

не, постоянно все ваши треды скипаю

как-то нет времени кому-то доказывать, что кто-то в интернете не прав)

хотяя...

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

тупо не согласен так как просто отстаиваю свою точку зрения, аргументами

"Аргументы" пишется, через "а".
Не дорос, не дорос.

- ты никогда ни с чем не соглашаешься!
- не согласен

да.. согласен. пойду поправлю.. а то стыдно