DN
Size: a a a
2018 June 18
DN
если вы необычный разработчик и у вас интересная история - напишите мне в лс, гугл приедет и снимет о вас видео
ВБ
если вы необычный разработчик и у вас интересная история - напишите мне в лс, гугл приедет и снимет о вас видео
Необычная это в каком плане? Какие-то физиологические отклонения или взаимодействие с какими-то необычными технологиями?
DN
все, если делал приложение для спасния уток в офисе, или живешь в бункере, спасаясь от ядерной войны и делаешь игру
GR
Привет, у меня еще вопросы по UI-тестированию: в одном из выпуском рассказывали про Espresso idling resources, о том что это не панацея и предлагали решения вроде цикла с Thread.sleep. Много кто такой подход использует? Какую делаете проверку на доступность вью? Может быть кто то находил библиотеки с подобными проверками или писал свою?
NK
Ужас. Кто-то всерьез может советовать цикл с sleep?
NK
Чем espresso idling resource не подходит?
GR
вроде как в подкасте был предпосыл что idling resource ждет пока не пройдут фоновые задачи, но не гарантирует что view будет доступна для взаимодействия
GR
Чем espresso idling resource не подходит?
А вы ожидаете доступность каждой вьюшки через этот механизм? А какое условие проверяете чтоб гарантировать что вью доступна и не перекрыта чем-то другим?
D
А вы ожидаете доступность каждой вьюшки через этот механизм? А какое условие проверяете чтоб гарантировать что вью доступна и не перекрыта чем-то другим?
Тест нужен для проверки, что вью доступна после выполнения фоновой задачи.
Иначе тест должен падать. А не ждать таймаута каждый раз.
Иначе тест должен падать. А не ждать таймаута каждый раз.
D
У эспрессо айдлинг ждет таймаута только если он неправильно внедрен, обычное поведение про ошибке в логике - тест падает сразу, а не по таймауту. Поэтому я тут не согласен с Артемом.
GR
Эмулятор (или устройство) может лагнуть и вьюшка будет недоступна в момент проверки, что вызовет флаканье теста, но продуктово бага нет, так как потом вьюшка доступка и кликабельна
D
Тут надо более предметно смотреть, что значит "лагануть"? Проверка же в конец лупера пихается, разве нет? Если в лупере есть задачи на отрисовку вью перед проверкой - они в любом случае раньше выполняться.
D
Вообщем я с таким не сталкивался, но и глубоко не копал.
GR
Вью может быть отрисована, но видима частично, клики работают когда вью видима больше чем на 90%
AK
Эмулятор (или устройство) может лагнуть и вьюшка будет недоступна в момент проверки, что вызовет флаканье теста, но продуктово бага нет, так как потом вьюшка доступка и кликабельна
Можно дожидаться определенно ресурса и без idling resources. 1) device.wait(Until.findObject...) это у uiautomator 2) написать лупер, который ходит по дереву контролов по view и лупит main thread - uiController.loopMainThreadForAtLeast(millis). Вариантов много)
D
Вью может быть отрисована, но видима частично, клики работают когда вью видима больше чем на 90%
На мой взгляд UI тест должен проверять, что данные видны юзеру. Если не видны - тест должен падать. Не видимо, или не отрисовано - уже вопрос починки теста.
D
Это костыли уже )
GR
На мой взгляд UI тест должен проверять, что данные видны юзеру. Если не видны - тест должен падать. Не видимо, или не отрисовано - уже вопрос починки теста.
Не очень подход, так как по факту бага нет, но тест флакает
GR
Можно дожидаться определенно ресурса и без idling resources. 1) device.wait(Until.findObject...) это у uiautomator 2) написать лупер, который ходит по дереву контролов по view и лупит main thread - uiController.loopMainThreadForAtLeast(millis). Вариантов много)
А готовых решений не посоветуете? Велосипед всегда успеем написать)