Ну тоже правда.
В любом случае, Роман поделился хорошим докладом, кому-то может быть полезен.
А наша дискуссия поможет решить, смотреть ли почти часовое видео.

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

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

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

А что ставишь-то?

Проблема в том, что я уже сегодня проходил этот этап и начинал установку. Но чет не зашло.. два часа устанавливалось,  но так и не установилось. Решил по новой и вот сейчас на этом затык.
Ставлю mint 19.2 cinnamon

Я вот думаю, а не могла ли моя загрузочная флешка пойти по борода..

Мб конфликты какие-то пошли..

Не помогло

Аааа.. не.. это я забуровил.. настройку в биосе поменял

Норм.   Завелось

Такое тоже может быть, чему однажды был посвящён куплет

Эм-Дэ-Пять, Эм-Дэ-Пять
пригодился, {животное}, {рифма}

А что такое md5 ?

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

> Совершенно замечательный.

Тоже нет :)

> Андрей достаточно подробно описал настоящие, скрытые, проблемы процессов и некоторые методы их решения.

А почему это "проблемы процессов"? Больше похоже на проблемы людей.

> С другой стороны, некоторые он обошёл стороной, когда, к примеру, не поделился опытом или рекомендациями, как внедрить бдд правильно, раз это хорошая идея

Прежде чем что-то внедрять, стоит подумать какую проблему оно (может?) решить, и стоит ли оно того.

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

Я смотрел в этом году несколько презентаций Антона Семенченко + Николая Алименкова, -- по теме автопроверок и ООП. (По БДД ещё старенький доклад Андрея Дзыни)
Одна из основных мыслей докладов, перефразируя: разные подходы, в том числе и ООП и паттерны, применяются для заворачивания сложности и решения проблем.
Если у вас нет сложности или не надо решать проблемы, то и наворачивать никаких решений не надо.
Не ломалось — не чини, нет проблем — не решай.

А ещё, опять таки на COMAQA Minsk 2019 посетил доклад Александра Пушкарёва:
____
Test club: If you need a framework - you do it wrong
15:20 - 16:00
В тест автоматизации, мы все любим продвинутые фишки: Page Object, Visual Testing, Model-based testing, машинное обучение и даже искусственный интеллект. Но что, если мы все поняли не так, и попросту нарушаем принцип KISS?
⠀ Добро пожаловать в Тест-минималистический клуб.
⠀ Первое правило клуба - если вы создаете сложное решение тест автоматизации - вы что-то делаете не так.
____

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

> По поводу паттерна Page Object и его реализации согласен, но в том числе возникает вопрос, а нужен ли он как концепция, именно в отношении страницы, а не, скажем, целиком веб-приложения.
> ... список локаторов объявляется единый для всего сайта/веб-приложения, поддерживается в одном месте и доступен всем тестам.

Тут полагается интересный вопрос о том какие проблемы мы решаем, с какими сложностями боремся, достаточно ли одного объекта для расфасовки нашей текущей сложности. Что если у нас на сайте сотни сущностей с разными локаторами и действиями?

> Есть иной вариант работы со страницей, и в нём BDD подход полезен -

Вопрос упаковки локаторов как бы не имеет никакого особого отношения к БДД, и вообще от Солнцева и Дзыни и Семенченко я скажу что БДД это подход фиксации определённых сценариев того ЧТО должно делать приложение (запечатляемая коммуникация, так сказать), а КАК оно будет записанные действия реализовывать — БДД не решает.

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

Предположение о "накоплении" нахожу крайне спорным. В статьях о реализации в Альфа-Банке и Тинькоффе они наоборот, хотели сузить возможность выбора "поведений" (по факту возможных действий после других возможных действий).

> мы просто в сценарии знаем где мы находимся, читая описание сценария и выполняем действия, которые хотим. В таком случае, тесты накапливают информацию о продукте, а не скрывают её.

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

> потихоньку зеленеющий тест

"потихоньку зеленеющий?" :)

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

Java это один из языков разработки, кросс-платформенный, с кучей библиотек. Выбирая язык, мы (уже давно) выбираем его экосистему -- где, как и с чем на этом языке можно работать.
Также тут же срач про типизацию, из-за которого любителям паттерна fluent interface, например, кроме Java может ничего и не заходить.

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

Чтобы было понимание, надо смотреть намного больше. Рекомендую таки того же Антона Семенченко (COMAQA).

Это с COMAQA доклад?

Да, той на которой я был. После НГ будут выкладывать.

Но основная мысль, в общем-то, проста как грабли — если можете без пейджобджекта сделать то же, что и с ним, то почему бы и не сделать без — быстрее работать будет (чем заведутся и стартонут всякие объекты на JVM).

Замечательный в рамках выбранной тематики, пусть и заголовок чистой воды clickbait. Он подсвечивает проблемы тем, кто с ними до этого мог не сталкиваться, или не имел опыта их решения. Даёт направления для поиска.

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

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

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

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

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

Тесты как-никак это сценарий из пункта А в пункт Б никуда не сворачивая, а не бесконечноживущее GUI-приложение по запуску и редактированию тестов (тесты зависимые от предыдущих результатов или порядка выполнения Андрей, на мой взгляд, справедливо обозначил как потенциальную проблему)


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

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

Насчёт упаковки - я имел в виду, что если мы в рамках реализации подхода БДД пробуем повысить читабельность тестов, как одно из рекламируемых преимуществ подхода, локаторы упакованные в понятные участникам проекта названия, помогают в целом тест сделать более доступным. Навскидку пример: пишем "пользователь нажал на кнопку {Далее в виджете логина через шапку}" вместо "пользователь нажал на кнопку {next}" и это уже делает конструкцию более доступной для прочтения без деталей реализации этих селекторов, достаточно будет названия из самого шага.