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

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

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

а с селениумом не так?

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

id - хорошо, но нахрена осмысленность?

селениум - драйвер для управления браузером. Существует на нескольких языках. Для запуска тестов на java нужен раннер (junit, testng), для сборки проека нужен сборщик (ant,maven,gradle), для отчетов нужен фреймворк(allure). Это по сути и плюс и минус опенсорса наверное =)

без id можно найти элемент по тексту, только если в таблице не 10 элементов с текстом "Сумма"

моё предложение - id = "o_%guid%" восприняли на ура

без id можно найти элемент по тексту, только если в таблице не 10 элементов с текстом "Сумма"

Xpath'ы же, или не актуально?

а вот когда их 10, тогда приходится изголяться Сумма[5]

у нас на одном проекте были id типа i_autogen164

xpath хорошо но чем сложнее тем дольше работает

без id можно найти элемент по тексту, только если в таблице не 10 элементов с текстом "Сумма"

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

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

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

а с селениумом не так?

селениум требует окружения: мне конечно сложно сравнивать с тест-комплитом - но требуется устаоновить еще как минимум драйвер на тестируемые браузеры; правильно их прописать в запуске тестов; установить какую-то библиотеку с тестами: TestNG, Junit, rspec или что-то другое; сборщик нужен: maven для java - bundler для руби и дальше исходя из реализации: пишем "просто тесты" - тогда можно не следовать шаблонам. Хотим page-object - берем какой-то вариант имплементации шаблона - библиотека ли, гем ли какой-то: по разному в разных ситуациях. Хотим выводить отчеты в html? То же начинаем придумывать "как и в каком виде": в итоге это конечно сводится "подключи библиотеку, пропиши 15 строк кода и будет счасть" - но перед этим приходится разобраться "как", "зачем" и "почему" в общем: запустить селениум это скорее "разработка приложения автотестов" - это несколько шире чем просто "писать тесты" - конечно все ИМХО

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

//*[text()="наше значение"] ?

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

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

//*[text()="наше значение"] ?

а таких полей в таблице с таким же текстом - 10 штук, тогда уж //*[text()="наше значение"](5) =)

а таких полей в таблице с таким же текстом - 10 штук, тогда уж //*[text()="наше значение"](5) =)

только [5]

а таких полей в таблице с таким же текстом - 10 штук, тогда уж //*[text()="наше значение"](5) =)

если их 10, то должен включится тумблер: "мы что-то делаем не так" - у элемента должен присутсвовать какой-то уникальный идентификатор: Если уж это автотесты - можно текст генерировать в ходе теста и их же и проверять: никто же не запрещает написать: "наше значение 123" - а при следующем выполнении "наше значение 124"

ну или тут недавно обсуждался вопрос: очищать данные после теста; то же вариант выхода :)

а в чём проблема деббага?

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

вопрос был про id. Идентификаторы это хорошо, но и без них тоже можно (сложнее но можно)

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

Из каких ресурсов? Ну и "заодно" в тест-кейсах не очень люблю. Мухи отдельно, котлеты отдельно. Проверка контента сама по себе, а привязываться в функциональных тестах, не знаю. Xpath на мой взгляд логичней

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

Именно для управления браузером, поэтому используем Selenide?

селениум требует окружения: мне конечно сложно сравнивать с тест-комплитом - но требуется устаоновить еще как минимум драйвер на тестируемые браузеры; правильно их прописать в запуске тестов; установить какую-то библиотеку с тестами: TestNG, Junit, rspec или что-то другое; сборщик нужен: maven для java - bundler для руби и дальше исходя из реализации: пишем "просто тесты" - тогда можно не следовать шаблонам. Хотим page-object - берем какой-то вариант имплементации шаблона - библиотека ли, гем ли какой-то: по разному в разных ситуациях. Хотим выводить отчеты в html? То же начинаем придумывать "как и в каком виде": в итоге это конечно сводится "подключи библиотеку, пропиши 15 строк кода и будет счасть" - но перед этим приходится разобраться "как", "зачем" и "почему" в общем: запустить селениум это скорее "разработка приложения автотестов" - это несколько шире чем просто "писать тесты" - конечно все ИМХО

Скачивание и определение драйвера можно запилить и в pom/build.gradle

И тогда руками не придется делать

Из каких ресурсов? Ну и "заодно" в тест-кейсах не очень люблю. Мухи отдельно, котлеты отдельно. Проверка контента сама по себе, а привязываться в функциональных тестах, не знаю. Xpath на мой взгляд логичней

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

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

А запустить отдельно упавший тест не судьба?

Из того что написали выше, ни одной проблемы не вижу

Само долго, это пилить конфиг и это разовая операция

Дальше пихаешь в CI и забываешь

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

Это отдельные тесты, на тот случай, если слово логин поменяли на слово вход. И если фейл, то я точно знаю почему

А на проверку текста кнопки которую можно получить только выполнив 100500 шагов вы тоже будете писать отдельный тест?

Конечно, а вы сотню проверок в один тест-кейс пихаете?

К тому же, вполне очевидно, что все зависит от ситуации и любой из этих подходов не является панацеей

Конечно, а вы сотню проверок в один тест-кейс пихаете?

а вы с таким не сталкивались?

а вы с таким не сталкивались?

Нет, не сталкивался

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

Конечно, а вы сотню проверок в один тест-кейс пихаете?

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

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

и вот тут придётся гнать с нуля

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

знаю-знаю, таких

А запустить отдельно упавший тест не судьба?

Я как раз про одни сценарий и говорил.

Как я уже сказал это не панацея. Все зависит от ситуации, и если у меня 10 элементов с текстом сумма, то лично я не уверен, что в этом случае буду привязываться к тексту

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

Так же не услышал ни одного контраргумента в пользу xpath

Вам так удобней, мне так, вот и вся разница

Я как раз про одни сценарий и говорил.

И в чем тогда проблема?

Локально прогнали один тестик, занимает не много времени

немного офисного оффтопа

немного офисного оффтопа

кажется склеено видео между 1 и 2 поворотами головы

офисный оффтоп можно во флудилку )

ооукей, но почему бы немного не разбавить серость))

Если UI на ангулярчике и он перепиливается - айдишники наше все. Иначе боль

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

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

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

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

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

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

если там выполняется ещё и js, то?

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

если там выполняется ещё и js, то?

ДЖ разный, пример, если можно)

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

выполняй JS напрямую/создавай сущность уже с нужными параметрами в БД

ERROR: S client not available

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

по вашим словам, ну жно будет сидеть ещё и высчитывать и анализировать, а чё такого поместить в БД, чтобы провести быстренько тестирование объекта, который упал в ошибку?

Эм

ну, у тебя ж автотест

определяешь изначальную сущность

выполняешь действия через UI

смотришь изменения в БД

автотест для того и создан, чтобы за меня всё выполнять

ну дык

а не чтобы я что-то за него выполнял

ты изменением БД через автотест перепрыгнешь UI с JS, если он так часто меняется

ты изменением БД через автотест перепрыгнешь UI с JS, если он так часто меняется

ой, то есть, мне ещё и автотест существующий менять нужно так, чтобы что-то там перепрыгивать, это уже тестирование ради тестирования какое-то

проще - перезапустить

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

lol

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

Идеальный тест - стабильный, тестирующий исключительно целевой функционал.

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

Всё зависит от того, есть понимание того, чем автоматизировать можно ваш объект

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

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

Что так, что так.

Спасибо

часто вот так происходит при запуске автотестов на opensource движках

вроде, всё хорошо-при хорошо, как надо, а потом кааак...полетит

Простой пример. Два теста: 1. Проверка возможности создания пользователя через форму регистрации. 2. Проверка что созданный пользователь сохраняется и им можно авторизироваться. Есть два частых варианта реализации. 1. И в первом и во втором тесте пользователь регистрируется через кнопочку "Регистрация". 2. Первый тест регистрирует пользователя по UI кнопке. Второй тест делает прямой POST запрос регистрации, а потом по кнопочке "Логин" авторизуется.

У тебя сломалась кнопка "Регистрация". В каком случае ты сможешь проверить максимум функционала несмотря на баг?

Что приведет к экономии времени после фикса? Ведь вдруг сломана и кнопочка "логин"?

И если сломана - програмисты сразу смогут фиксить обе ошибки

А как пользователь по вашему может зарегистрироваться на сайте, тоже через POST?)

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

да

нажмите Ф12 и посмотрите что происходить после клика на "Регистрация"