С какими инструментами для тестирования вы работали?

Что проверяют

Разделяете ли вы уровни тестов и понимаете ли, что в Android половина инструментов существует только потому, что фреймворк тяжело поднять на обычной JVM. Вопрос открытый, и по нему сразу видно, писали ли вы тесты сами или только видели чужие в проекте.

Как отвечать

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

• Локальные тесты на JVM, каталог test: JUnit как раннер, MockK или Mockito для заглушек, kotlinx-coroutines-test с runTest и подменой диспетчера, Turbine для проверки Flow, MockWebServer вместо живой сети.
• Инструментальные, каталог androidTest, идут на устройстве или эмуляторе: Espresso для вёрстки на View, createAndroidComposeRule и семантические матчеры для Compose, UI Automator, когда нужно выйти за пределы приложения, тестовое правило Hilt для подмены зависимостей.
• Robolectric стоит посередине: классы фреймворка эмулируются на JVM, тест быстрый, но это не настоящее устройство, и часть поведения там приблизительная.
• Вокруг: прогон на облачной ферме устройств или на матрице эмуляторов в CI, скриншотные тесты, отчёт о покрытии.

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

Где спотыкаются

Перечисляют инструменты, но не могут сказать, где тест запускается. Espresso в каталоге test просто не заведётся, а Robolectric не заменяет прогон на устройстве. Путаница ровно в этом месте выдаёт, что тесты в проекте писал кто-то другой.

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

Третье: мокают всё подряд, включая сам тестируемый класс, и проверяют не результат, а порядок вызовов. Такой тест краснеет на любом рефакторинге и при этом не ловит ни одной настоящей ошибки.