на скрам доске или канбане?

А зачем это если есть сабтаски ?

Затем, что сабтаски в большинстве случаев - излишняя и бесполезная сущность.

Кстати, джироводы. Есть вопрос. Как можно в в джире настроить такой кейз: Ежедневно в заданное время (например, в 18:00 вечера) создаётся страничка в которой записываются открытые тикеты из текущего спринта, например. Или подобного рода фильтр вставляется. Реально это сделать?

не понял зачем, на доске-то и так все видно

страничка в джире? мб конлфюенс?

да, в конфлюенс.

не понял зачем, на доске-то и так все видно

Человеку нужен снэпшот доски на определенное время.

Человеку нужен снэпшот доски на определенное время.

Верно.

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

у Confluence есть API на публикацию пейджи. У Jira есть API на выхватывание нужноого тебе фильтра по таскам.

Кстати, есть в чудесном TargetProcess из коробки. https://www.targetprocess.com/guide/progress-measures-metrics/effort-estimation-progress/reports-effort/reports-effort-by-role/

https://youtrack-support.jetbrains.com/hc/en-us/community/posts/205797809-Custom-Field-Workflow

подружить это темплейтом на markdown'е. записать скриптом, положить в crontab

https://youtrack-support.jetbrains.com/hc/en-us/community/posts/205797809-Custom-Field-Workflow

Вы читали, про что там?

Человек хочет поле со значением int, исходя из которого меняется стандартное поле estimate.

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

Кстати, джироводы. Есть вопрос. Как можно в в джире настроить такой кейз: Ежедневно в заданное время (например, в 18:00 вечера) создаётся страничка в которой записываются открытые тикеты из текущего спринта, например. Или подобного рода фильтр вставляется. Реально это сделать?

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

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

наверное, я неправильно пояснил. Мне нужно, чтобы кастомер открыл определенную страницу. Например, в за 1 августа 2017 и увидел, что в 18:00 было столь-то в опен таких-то, столько-то в резолвах таких-то.

а, чтобы история сохранялась ежедневная?

Я выше описал подход

@RichardGears

нужно только придумать фильтр. например, все такси проекта, включенные в конкретный спринт

Это динамическая страница, она не будет хранить историю

Требованием была возможность иметь стопку страниц на каждый день

Это динамическая страница, она не будет хранить историю

Верно.

Если бы надо было просто фильтр поставить, который будет показывать ТЕКУЩИЕ статусы - проблем бы не было.

скриншоть их и все)

Автогенерация - задача крона или любого другого планировщика. Публикация - задача post апи. Агрегация данных - задача get апи

Я Ричарду предложил вариант, но его не устроило :(

1 день чтения мануалов, сделаю вам на выходных за 35 Бачей в час

За 3/4 часа

Я Ричарду предложил вариант, но его не устроило :(

Не. Не не устроило. Буду пробовать и обсуждать.

1 день чтения мануалов, сделаю вам на выходных за 35 Бачей в час

Написал в личку.

В Unittest есть возможность автоперезапуска зафейленных тестов задаваемое количество раз?

нормально из коробки – нет, лучше взять pytest

нормально из коробки – нет, лучше взять pytest

Но, может есть обходные пути? Поделитесь опытом)

Но, может есть обходные пути? Поделитесь опытом)

трайэксепт

9\10 разработчиков на python посоветуют пользоваться де-факто стандартным уже pytest для тестирования. или Nose.

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

все равно что использовать urllib вместо requests

не в то окно)

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

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

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

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

просто тесты плохо написаны и надо написать их хорошо

раннер тут ни при чем

раннер тут ни при чем

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

Раннер другой нужен для автоперезапуска упавшего теста

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

Не всегда это возможно.

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

И это тоже)

Не всегда это возможно.

звучит как отговорка сделать гибкие, быстрые тесты

звучит как отговорка сделать гибкие, быстрые тесты

Приведу пример. Есть выпадающий список, под ним кнопка. Раскрытый список перекрывает кнопку, нужно ждать, пока он скроется. Ожидания не помогают, вылетает unknown error. Помогает секундный time.sleep, но на глючном тест сервере он может иногда закрываться дольше. Соответственно, тест падает.

Приведу пример. Есть выпадающий список, под ним кнопка. Раскрытый список перекрывает кнопку, нужно ждать, пока он скроется. Ожидания не помогают, вылетает unknown error. Помогает секундный time.sleep, но на глючном тест сервере он может иногда закрываться дольше. Соответственно, тест падает.

Такая же фигня. Ожидания на полсекунды-секунду, чтобы анимация отработала. wait.until по каким-то причинам не справляется с этим. Но для здешних пуристов это увы, не аргумент

Приведу пример. Есть выпадающий список, под ним кнопка. Раскрытый список перекрывает кнопку, нужно ждать, пока он скроется. Ожидания не помогают, вылетает unknown error. Помогает секундный time.sleep, но на глючном тест сервере он может иногда закрываться дольше. Соответственно, тест падает.

У нас с тобой просто кривые руки, смирись :)

Филипп, все правильно сказал

Такая же фигня. Ожидания на полсекунды-секунду, чтобы анимация отработала. wait.until по каким-то причинам не справляется с этим. Но для здешних пуристов это увы, не аргумент

Ну хоть одна “родственная душа” в этом чате

Такая же фигня. Ожидания на полсекунды-секунду, чтобы анимация отработала. wait.until по каким-то причинам не справляется с этим. Но для здешних пуристов это увы, не аргумент

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

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

Но я, наверное, просто "здешний пурист", не понимающий всех прелестей захардкоженных слипов.

слипы иногда проще чем правильные вейты)

но не правильнее

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

waitUntilClickable тоже не всегда отрабатывает, кстати

но 99% отрабатывает

waitUntilClickable тоже не всегда отрабатывает, кстати

В целом это зависит только от реализации.

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

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

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

"Не делает что требуется" это вам вебдрайвер возвращает "visible && clickable == true" когда элемент скрыт за другим?

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

А у меня была такая фигня, что интересно, работала лучше, но из-за того же пуризма (ха-ха) я ее выкинул, мол Селениум хороший, пусть будет только чистый wait.until

Unknown error: element... is not clickable at point (...,...). Other element would receive the click: ....

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

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

Unknown error: element... is not clickable at point (...,...). Other element would receive the click: ....

Выглядит как вполне осмысленная ошибка.

Даже есть намек на то, в каком направлении надо копать.

Это при использовании ожиданий...

Это при использовании ожиданий...

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

Втыкаете print(Element.clickable?) под это ожидание и смотрите, что оно вам возвращает.

например, у вас обернуто все в span и вы пытаетесь кликать по нему

Если оно вернет clickable -> вариант Евгения выше. Если вернет не-clickable -> делаете цикл из sleep(0.1) до тех пор, пока не будет clickable == true и смотрите, решит ли это проблему.

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

Unknown error: element... is not clickable at point (...,...). Other element would receive the click: ....

Потому что что-то мешает

Click целится в центр элемента, если какой-то элемент перекрывает, то будет данная ошибка

Как фиксить: либо выбирать правильно локатор, либо если это блокирует тест,то убирать элемент перекрывающий (бывает что сверху есть другой элемент, но внешне на UI не влияющий, решается с верстальщиком или фронтендером)

Unknown error: element... is not clickable at point (...,...). Other element would receive the click: ....

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

Потому что что-то мешает

Мешает как раз выпадающий список, который долго закрывается.

Мешает как раз выпадающий список, который долго закрывается.

Дождаться его закрытия

Дождаться его закрытия

я так и делаю, при помощи time.sleep

и это антипаттерн

сделали в одном месте, в другом, в третьем - потом тесты вместо 3 минут суммарно выполняются 84. Цена раскиданных явных time.sleep

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

а еще чисто с эстетической точки зрения автоматизация -это про экономию времени. неужели не хочется ускорить тесты на 500-600%.

всего лишь заменив time.sleep(5) на wait.until

всего лишь заменив time.sleep(5) на wait.until

я изначально так пытался сделать. Времени потратил уйму, но так и не добился результата. Не работает там wait.until...

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

если бы локатор был не тот, то тест вообще бы не работал. А с time.sleep работает

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