И немного отвлечёмся от китайских ботов на UI automation http://qa-blog.alexei-vinogradov.de/2018/07/kiss-driven-test-automation-и-вопросы-о-статистике-успеха/

На мой взгляд, слишком абстрактно получилось. KISS, в отличие от SOLID, GRASP и DRY самый толковый, но и самый размытый из всех "принципов", поэтому вещать за него, действительно не стоит(это как сказать "ребят, ну надо хороший код просто писать"), но доклад, тем не менее крутой, хотя бы из-за "не пишите фреймворки, пишите код"

Доклад хороший. Вот только я бы его переименовал в "Mastering selenide". В условиях работы на основе Селенида информация интересна и правильна и даст хороший старт новичку в данном врапере. Но тема доклада и некоторая подача все таки базировалось на подход в целом. А в условиях вот уже нативного Селениума или дргих фреймворков которые уже не используют такие подкапотные динамеческие кондишены, подобные советы могут ,я бы даже сказал, навредить. А ведь как вы сами заметили Селенидом пользуется чуть большая часть аудитории. Соответсвенно часть аудитории может впитать и не совсем то что нужно. В целом доклад хороший и интересный вот только посыл, как мне кажется, стоило чуть специфицировать.

что касается паттернов, то сам Солнцев еще 3 года назад писал на своем сайте, что можно вполне себе жить без пейдж обжект паттерна =)

что касается паттернов, то сам Солнцев еще 3 года назад писал на своем сайте, что можно вполне себе жить без пейдж обжект паттерна =)

До сих пор говорит. Так и можно же)

На мой взгляд, слишком абстрактно получилось. KISS, в отличие от SOLID, GRASP и DRY самый толковый, но и самый размытый из всех "принципов", поэтому вещать за него, действительно не стоит(это как сказать "ребят, ну надо хороший код просто писать"), но доклад, тем не менее крутой, хотя бы из-за "не пишите фреймворки, пишите код"

Спасибо! Как раз новый вариант с бритвой более конкретно объясняет когда "обрезать", ну и примеры для ui и Selenide конкретные. А так да, писать KISS код сложно. Учимся потихоньку

0,

Доклад хороший. Вот только я бы его переименовал в "Mastering selenide". В условиях работы на основе Селенида информация интересна и правильна и даст хороший старт новичку в данном врапере. Но тема доклада и некоторая подача все таки базировалось на подход в целом. А в условиях вот уже нативного Селениума или дргих фреймворков которые уже не используют такие подкапотные динамеческие кондишены, подобные советы могут ,я бы даже сказал, навредить. А ведь как вы сами заметили Селенидом пользуется чуть большая часть аудитории. Соответсвенно часть аудитории может впитать и не совсем то что нужно. В целом доклад хороший и интересный вот только посыл, как мне кажется, стоило чуть специфицировать.

Тут есть тонкость. Большинство экспертов считает, что тесты на чисто селениуме (ну кроме как тренировочных) писать нельзя. В реальных проектах надо или писать свой фреймворк или брать что-то готовое. Мои примеры (по понятным причинам) -на Селениде, но некоторые из них 1:1 например на протрактор переносятся. Рабочих фреймворков слишком много, чтобы выискивать для каждого соответствия, но мне кажется те кто хотят - легко найдут параллели.

еще хорошо, когда pageobject генерируется автоматически для всех страниц сайта)

еще хорошо, когда pageobject генерируется автоматически для всех страниц сайта)

Что для тебя страница сайта в современном single page application приложении?

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

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

ну думаю хорошо, если заходишь на первую страницу сайта, а там есть уже js объект в котором есть все виджиты, кнопки и id всех элементов

Ясно.

Этот js объект генерируется самостоятельно или описывается ручками?

автоматически

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

можно было создать свою страницу накидать на нее компонентов и автоматически сгенерировать класс со всеми page object элементами и писать тесты

Можно сделать троллейбус из буханки хлеба.

еще хорошо, когда pageobject генерируется автоматически для всех страниц сайта)

Заблуждение)

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

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

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

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

Плюсы и минусы, где-то может хорошо работать, где-то не очень

везде есть + и - )

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

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

люблю утверждения, начинающиеся со слов "большинство экспертов считает" :)

Народ, iOS апп с. 3.2 пытаюсь запустить XCTest на UI automation тест кейсы вообще(точнее запускается после launch сразу закрываться)run не проходит и ошибок тоже нету просто пишет success и все. Проверил target тоже проблем нету

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

Разрабы е2е тесты прогнали и поправили?

Ну да. Почему бы и нет? :)

Ну гнать е2е сомнительная идея из-за таймингов: я знаю контору у которой подготовка окружения и прогон занимали 3 дня))) Даже выборочный прогон может отправить разработчика курить минут на 20, а разработчики нынче конских денег стоят. Более того, у разрабов обычно есть свои тестовые "подушки" (юниты, интеграционные тесты и т.д.) которые бегут сильно быстрее. Вот тут полнее дядя написал про это: “Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst” @fistsOfReason https://medium.com/@fistsOfReason/testing-is-good-pyramids-are-bad-ice-cream-cones-are-the-worst-ad94b9b2f05f

Про поправили тут еще более спорно: дело в том, что у вас свои приколы, а у нас свои. Вы совсем по-другому пишите, у вас свои паттерны, фреймворки...да даже стайл-гайды могут быть другими. Если разработчик залезет в тест и увидит там все вот эти page-object'ы обмазанные кукумбером, то он в лучшем случае ничего не поймет, а в худшем случае поправит-сломает-подопрет костыликом-и так сойдет

Не говоря уже о том, что у нас, например, бекенд на .net, фронт на js, а автоматизация на java

Может я не прав, конечно, но мне всегда казалось, что лучше выходит когда каждый делает свое дело: тестирование пишет тесты, разработка разрабатывает, ci/cd запускает :)

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

с юнитами так часто бывает; но не везде разработчики вообще взаимодействуют с end-to-end сценариями

я не про unit тесты

Ну гнать е2е сомнительная идея из-за таймингов: я знаю контору у которой подготовка окружения и прогон занимали 3 дня))) Даже выборочный прогон может отправить разработчика курить минут на 20, а разработчики нынче конских денег стоят. Более того, у разрабов обычно есть свои тестовые "подушки" (юниты, интеграционные тесты и т.д.) которые бегут сильно быстрее. Вот тут полнее дядя написал про это: “Testing is Good. Pyramids are Bad. Ice Cream Cones are the Worst” @fistsOfReason https://medium.com/@fistsOfReason/testing-is-good-pyramids-are-bad-ice-cream-cones-are-the-worst-ad94b9b2f05f

Даже если тесты бегут 3 часа - это часто слишком много. Признак того, что что-то сделано не так. А как программисты убедились в том, что после смены вёрстки функциональность не сломалась? Тесты должны помогать баги раньше выявлять, стоимость починки бага (супер дорогим программистом) тем выше, чем позже он обнаружен.

Даже если тесты бегут 3 часа - это часто слишком много. Признак того, что что-то сделано не так. А как программисты убедились в том, что после смены вёрстки функциональность не сломалась? Тесты должны помогать баги раньше выявлять, стоимость починки бага (супер дорогим программистом) тем выше, чем позже он обнаружен.

Другими тестами/е2е запущенным перед функциональным тестированием или найтли-билдом

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

Другими тестами/е2е запущенным перед функциональным тестированием или найтли-билдом

Если другие тесты ловят проблемы при изменении вёрстки - то ок (юнит и интегр - редко для вёрстки бывают). Тогда вопрос зачем вообще нужны эти доп тесты и может быть их просто удалить?

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

E2E на пул-реквест - нормас. Чтобы разраб не ждал три дня есть CI/CD и автоматизация подготовки окружения. У тестировщиков фреймворки ни фига не магические, разрабы в unit'ах больше магии делают. Если локатор сложно написать - то может разрабу как раз легче айдишник в коде добавить. Если пэйджи готовы и есть дока к тесту, то там вообще все понятно должно быть. Плюс разраб большей экспертизой обладает и может зарефакторить код теста. Ну и последнее, все его изменения через ревью пойдут, так что ему объяснят, где он сломал и он больше так не будет.

Дока к тесту. Т.т

Если другие тесты ловят проблемы при изменении вёрстки - то ок (юнит и интегр - редко для вёрстки бывают). Тогда вопрос зачем вообще нужны эти доп тесты и может быть их просто удалить?

Ну на счет верстки, честно говоря, на 146.6% утверждать не могу(вообще фронтенд с тестами видел крайне редко), но прогоны е2е ночами практиковали

Пойду, пожалуй, тоже за kiss проповедовать.

E2E на пул-реквест - нормас. Чтобы разраб не ждал три дня есть CI/CD и автоматизация подготовки окружения. У тестировщиков фреймворки ни фига не магические, разрабы в unit'ах больше магии делают. Если локатор сложно написать - то может разрабу как раз легче айдишник в коде добавить. Если пэйджи готовы и есть дока к тесту, то там вообще все понятно должно быть. Плюс разраб большей экспертизой обладает и может зарефакторить код теста. Ну и последнее, все его изменения через ревью пойдут, так что ему объяснят, где он сломал и он больше так не будет.

Е2е на пул-реквест нормас, если можно выбирать нужные е2е из пачки, иначе 3 дня на каждый ПР CI/CD - это прекрасно, расскажите теперь какому-нибудь банку про то, что им надо весь софт через дженкинс на стенд выращенный солтом или ансиблом научиться катать. В юнитах магии быть не может, или это не юниты Ревью не отлавливает ошибки и баги А в остальном согласен)))

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

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

откройте его на запись и не закрывайте

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

а как ошибки через ревью отлавливать? в голове код запускать? а чем дженкинс не угодил? ну давайте на ТС или Бамбу поменяем) не держите в себе)

а как ошибки через ревью отлавливать? в голове код запускать? а чем дженкинс не угодил? ну давайте на ТС или Бамбу поменяем) не держите в себе)

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

И нет, к дженкинсу у меня претензий нет.

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

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

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

читайте про exclusive lock'и для конкретной ОС

можете найти утилиты\написать сами на python\java\etc код который будет захватывать файл\папку

читайте про exclusive lock'и для конкретной ОС

.dll же, понятно какая ОС

хотя я дллки и на юниксе заводил, через ctypes

я дал генерализованный ответ :S хоть коня рогатого можно будет лочить

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

А, т.е. вы ревью проходите по принципу "я понимаю, как это работает, но думать правильно ли это - не буду".

Резонный подход (нет).

Удалось залочить обычным текстовым редактором

Удалось залочить обычным текстовым редактором

неожиданно)

А, т.е. вы ревью проходите по принципу "я понимаю, как это работает, но думать правильно ли это - не буду".

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

Действительно не смешно. :)

ну например я на ревью отловил каскад-делит половины development базы. Что с этим не так?

А испанца, который это написал, уволили.

ну например я на ревью отловил каскад-делит половины development базы. Что с этим не так?

Но концептуально то норм работает.

ну например я на ревью отловил каскад-делит половины development базы. Что с этим не так?

все с этим хорошо, вы молодец. Но если бы не вы, то это должны были тесты на стенде найти

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

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

ну вот это похоже на воркфлоу здорового человека, да)

Но концептуально то норм работает.

it depends

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

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

не, ревью неизбежно, это понятно

желательно чтобы несколько человек

it depends

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

плюс у нас включены аппрувы по ревью, должно быть не менее 2х аппруверов. А когда все аппрувы получены стартует вебхук, который запускает test&merge, который уже прогоняет вообще все тесты, а потом сам мержит)

плюс у нас включены аппрувы по ревью, должно быть не менее 2х аппруверов. А когда все аппрувы получены стартует вебхук, который запускает test&merge, который уже прогоняет вообще все тесты, а потом сам мержит)

похоже на наш воркфлоу :)

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

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

Звучит довольно стандартно.

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

Нет depends. Еще раз: одно дело понимать как это работает, и совсем другое проверка корректности.

Лол.

Выше уже комментировал.

Лол.

Вот да

Теплое\мягкое, вот это все

Окей, окей. Действительно, зачем задумываться лишний раз о том, что ревьюишь.

Концептуально-то ок.