Build instrumented tests
Дає офіційну точку входу до native Android UI tests і synchronization model.
Типи мобільних застосунків та мобільна автоматизація → Першоджерело ↗Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Дає офіційну точку входу до native Android UI tests і synchronization model.
Типи мобільних застосунків та мобільна автоматизація → Першоджерело ↗Для кожного Page Object або повторно використовуваного компонента потрібна операція, яка доводить готовність до подальших дій. Вона локалізує причину падіння: замість випадкової помилки наступного кроку тест одразу повідомляє, що сторінка не завантажилася або потрібний блок не з’явився. Критерій залежить від rendering strategy. У client-side rendering можуть послідовно з’являтися skeleton, дані й зображення; інша сторінка приховує весь content до завершення кількох requests. Перевіряти треба мінімальний набір елементів, без яких сценарій не може продовжуватися, а не чекати кожної можливої деталі.
Selenide condition на кшталт `shouldHave(text(...))` очікує потрібний стан протягом певного часу, тоді як `getText()` плюс JUnit assertion читає значення лише один раз. Якщо frontend спочатку показує `0`, а потім `102`, одноразове читання може зробити тест flaky. Перед статичною числовою перевіркою слід хоча б дочекатися видимості або іншої надійної precondition; повторюваний parsing виноситься в один method.