Почему не был рассмотрен вариант использования Concurrency API, для решения задач с поджиданием всяких шустрых элементов в отдельном неблокирующем потоке?
Про первый сценарий, который якобы НИКАК не протестить, чтобы тест был неморагющий. Всё просто. Шаги should appear или should disappear не должны иметь таймаута 4 сек. Этот таймаут должен быть намного больше (а разумных пределах, с учетом самых тормозных браузеров и систем, ну скажем 1 мин). И тогда шаг валидации дождётся появления Saving. А затем дождётся исчезания. Моргнуть такой тест может, если браузер или винда подвиснет. Но это уже исключительный случай.
Ну, так можно увеличивать таймаут до бесконечности. Ну да, можно. Некоторые кейсы это решит, но не все. Но разве это вообще нормально в 21 веке, что какое-то действие на UI длится дольше 4 секунд? Не правильнее ли вместо увеличения таймаута разобраться, что там тормозит? Если оно в тестах так тормозит, что же в продакшине будет?
@@EugeneM Ну да, если какой-то конкретный шаг ожидаемо может занять более 4 секунд, то ему можно явно указать таймаут побольше. Всё это легко делается. Типа $.should(appear, Duration.ofSeconds(60)). НО Этот тест всё равно может моргнуть, если запрос, наоборот, очень быстрый. Тогда может случиться, что надпись "Saving" успела появиться и пропасть до того, как тест начал ожидать её появления.
Вот это заявка. :) Так всё на свете недопиленная! Ну так заведи issue, расскажи, что следует допилить. Ну и допили по возможности. Это ж опенсорс так-то.
@@andrei.solntsev на 36 минуте начал рассказывать что настроен дженкинс чтобы билдить новую ветку - можно подробнее как реализовано, и как гонять лишь один тест
@@QwinTube Так это как раз легко. Создаёшь ветку, добавляешь в build.gradle или pom.xml строчку типа "include **/MyTest*" и погнали. Здесь подробнее: ua-cam.com/video/LDjDtR6kd2c/v-deo.html - с 11:57
Почему не был рассмотрен вариант использования Concurrency API, для решения задач с поджиданием всяких шустрых элементов в отдельном неблокирующем потоке?
Про первый сценарий, который якобы НИКАК не протестить, чтобы тест был неморагющий.
Всё просто. Шаги should appear или should disappear не должны иметь таймаута 4 сек. Этот таймаут должен быть намного больше (а разумных пределах, с учетом самых тормозных браузеров и систем, ну скажем 1 мин). И тогда шаг валидации дождётся появления Saving. А затем дождётся исчезания. Моргнуть такой тест может, если браузер или винда подвиснет. Но это уже исключительный случай.
Ну, так можно увеличивать таймаут до бесконечности. Ну да, можно. Некоторые кейсы это решит, но не все.
Но разве это вообще нормально в 21 веке, что какое-то действие на UI длится дольше 4 секунд? Не правильнее ли вместо увеличения таймаута разобраться, что там тормозит? Если оно в тестах так тормозит, что же в продакшине будет?
@@andrei.solntsev запросто может на UI что-то ждать более 4 сек, особенно при обращении к бэкэнду. Плюс может быть какой то глюк сети.
@@EugeneM Ну да, если какой-то конкретный шаг ожидаемо может занять более 4 секунд, то ему можно явно указать таймаут побольше. Всё это легко делается. Типа $.should(appear, Duration.ofSeconds(60)).
НО
Этот тест всё равно может моргнуть, если запрос, наоборот, очень быстрый. Тогда может случиться, что надпись "Saving" успела появиться и пропасть до того, как тест начал ожидать её появления.
selenide - обертка не допиленная, если честно
Вот это заявка. :)
Так всё на свете недопиленная!
Ну так заведи issue, расскажи, что следует допилить. Ну и допили по возможности. Это ж опенсорс так-то.
о, а вот и эспертное мнение подъехало, как всегда с аргументами)). Держи в курсе
в общем понятно кому теперь жаловаться когда bspb в очередной раз висит )
Это даже мне непонятно...
@@andrei.solntsev на 36 минуте начал рассказывать что настроен дженкинс чтобы билдить новую ветку - можно подробнее как реализовано, и как гонять лишь один тест
@@QwinTube Так это как раз легко. Создаёшь ветку, добавляешь в build.gradle или pom.xml строчку типа "include **/MyTest*" и погнали.
Здесь подробнее: ua-cam.com/video/LDjDtR6kd2c/v-deo.html - с 11:57