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

Docker version 1.12.6, build 85d7426/1.12.6

сейчас же уже 17 версия

поставь актуальню ?

с сайта у них

в yum репе старая версия лежит

а что в логе контейнера с хромом?

где хранится?

docker logs имя-контейнера

Исходные данные: использую робот фреймворк для тестов под селениум. Из консоли тесты выполняются нормально(ожидаю пока элемент появится на странице). Проблема: при попытке запилить это всё под дженкинс, то под дженкинсом периодами получаю вылет с тем, что элемент невидим. Судя по скриншотам, элемент есть, но страница не успела прогрузиться и доскролиться до нужного элемента. Вопрос: не подскажете как с этим бороться? Изменить условия ожидания элемента на странице на условие появления+видимости? Можно покидать ссылками как правильно организовывать тесты с подобными примерами, если у кого под рукой есть :)

Заменить все захардкоженный ожидания на smart wait.

@azshoo Шо это такое и где на него посмотреть?

В целом в гугле, но вот в качестве примера: http://toolsqa.com/selenium-webdriver/advance-webdriver-waits/

Гуглил на ходу, но на первый взгляд довольно подробно и корректно изложено.

спасибо. но про FluenWaits я вчера древнее видео от Баранцева смотрел. но тут придётся писать свою реализацию...

или искать уже готовую, если таковые есть...

Ну, реализация занимает строк 10 кода, но можно спокойно нагуглить готовую реализацию или вдохновиться примером из исходников протрактора.

так тож реализация, а тож тащить её использование совместно с Selenium2Library

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

Бан ксении за матерные стикеры и спамеру за видосы. ВЖУХ!, да.

Здравствуйте всем. Скажите, кто-нибудь допиливал allure адаптер (или как он там точно называется, извините если попутал) для nunit 3? Вроде как яндексовцы отдали его на совесть комьюнити, если память не изменяет?

допиливал. Но полнофункциоанального там пока ничего нет

допиливал. Но полнофункциоанального там пока ничего нет

Ясно, спасибо.

можно сюда глянуть https://github.com/unickq/allure-nunit или клепать с https://github.com/allure-framework/allure-csharp

вот пример моей реализации: https://github.com/undron/NUnitAllureBase

Ага, супер.

Наверное, придется в отпуске заняться)

А вот этот unickq вы не тестили?

тестил, но нам не сильно это подходит, да и влом над каждым тестом писать столько аттрибутов

Как лучше делать? Заранее все сущности создать в базе или перед началом теста создавать(через апи)? То есть для каждого теста вначале будут создаваться данные нужные именно для этого теста

Как лучше делать? Заранее все сущности создать в базе или перед началом теста создавать(через апи)? То есть для каждого теста вначале будут создаваться данные нужные именно для этого теста

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

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

+ не будут ли портиться данные в базе?

из-за тестов

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

а есть возможность подсчистить за собой?

так же быстро

Да тоже через апи можно базу снести

Лично я бы выбрал вариант создать-заюзать-удалить

Как лучше делать? Заранее все сущности создать в базе или перед началом теста создавать(через апи)? То есть для каждого теста вначале будут создаваться данные нужные именно для этого теста

оба варианта имеют плюсы и минусы и применимы различным образом в различных условиях

но тут смотря что вам нужно)

оба варианта имеют плюсы и минусы и применимы различным образом в различных условиях

+

Всем привет! Тут возник вопрос, сам раскурить не смог. ? Дано: 1. Jenkins с плагином Blue Ocean, бегущий в докере (офицально рекомендуемый вариант, основанный на alpine linux) 2. Тесты фронтенда, использующие puppeteer (chrome-headless) Проблема: Puppeeter не рабоатет в alpine linux. Гугление и нахождение возможных вариантов решения проблемы (типа установки зависимотей в контейнер с Jenkins не помогли). Предложите варианты решения?

оба варианта имеют плюсы и минусы и применимы различным образом в различных условиях

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

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

сделайте один тест и так и так, посмотрите как лучше, на реальном примере вам рассуждать что лучше, легче будет)

У меня так уже есть как по мне так апи норм )) как по снению другого чувака база рорм

а вы не можете испортить тестовые данные в базе?

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

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

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

Далее фактор времени: Действия, перед тестами могут вызываться во многих кейса - и, например, создание пользователя - занимающее 5-7 секунд через апи, инициированное сто раз сделает длительность выполнения тестов ~10 минут. Если простое использование имеющихся данных закрывает ту же потребность внутри тестов и занимает 2-3 секунды - то на те же 100 случаев получится ~4-5 минут - что сократит общее время выполнения тестов.

конечные критерии для выбора Заготовок и Создания данных - нужно определять для каждого конкретного случая.

все ИМХО - готов обсудить, если кто не согласен :)

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

У меня так уже есть как по мне так апи норм )) как по снению другого чувака база рорм

при before-test-after у тебя вся логика проверки сгруппирована в одном месте и удобно вносить изменения. если будет некий super pre condition с базой, то при частых изменениях можно не уследить за необходимым кол-вом создаваемых элементов и тем что по факту используются в тестах. то есть не все так очевидно получается. ты не сможешь прочитать в тесте: "тут я создаю 4 объекта - провожу тест - удаляю 4 объекта".

при before-test-after у тебя вся логика проверки сгруппирована в одном месте и удобно вносить изменения. если будет некий super pre condition с базой, то при частых изменениях можно не уследить за необходимым кол-вом создаваемых элементов и тем что по факту используются в тестах. то есть не все так очевидно получается. ты не сможешь прочитать в тесте: "тут я создаю 4 объекта - провожу тест - удаляю 4 объекта".

как раз таки могу

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

ERROR: S client not available

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

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

Вообще все те же вопросы тут из раза в раз уже обсуждались ранее

Женя, жизнь циклична.

Действительно, даже я в чат вернулся. И на мои долбанутые вопросы снова не отвечают.

И на это я уже жаловался. ?

А что можно ответить на твой вопрос, собственно? Ты используешь две несовместимые между собой технологии, получаешь тыкву. Вариант: не используй их.

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

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

Или не использовать паппитир, а брать селениум.

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

this https://github.com/GoogleChrome/puppeteer/issues/290 and this https://github.com/GoogleChrome/puppeteer/issues/379

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

Вообще все те же вопросы тут из раза в раз уже обсуждались ранее

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

вывод что-то создавать в базе что-то создавать перед самим тестом

Формально, если локально всё работает, а в докере падает, то очевидна проблема версионности зависимостей. Если в докере у тебя будет та же версия всех dependencies, что и вне оного - оно заведется. Хардкодить в конфиге все версии вплоть до минорных - так себе план, но должно решить проблему.

вывод что-то создавать в базе что-то создавать перед самим тестом

Какой-то странный вывод ты сделал из спора, который кончился тем, что "у всего есть свои плюсы и минусы", честно говоря.

взять плюсы из каждого подхода и сделать комбинированный способ =)

И получить все минусы и неконсистетность в добавок, да. :)

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

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

Не очень понимаю: "Зачем?"

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

this https://github.com/GoogleChrome/puppeteer/issues/290 and this https://github.com/GoogleChrome/puppeteer/issues/379

Конечно, я все это читал и пробовал. Но все равно спасибо. А переезжатьт на Selenium на данный момент не очень реально в нашей реальности.

Ну, окей, Саша. Проблема: та же что в issues или другая?

Ну, окей, Саша. Проблема: та же что в issues или другая?

Можно сказать, что да.