Какой у вас опыт с unit, UI и snapshot тестами в iOS?

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

Понимаете ли вы, какой вид теста что ловит и сколько он стоит. Интервьюер хочет услышать про пропорции и про то, как тесты живут в CI. Следом обычно спрашивают, как вы подменяете сеть и что делаете с нестабильными UI-тестами.

Как отвечать

Разложите опыт по трём уровням:

• unit: основная масса тестов. Бизнес-логика, ViewModel, парсинг, форматирование. Долго это был только XCTest, с Xcode 16 появился Swift Testing: @Test, #expect, #require, параметризованные тесты через arguments:. Скажите, на чём пишете новые тесты, обе библиотеки уживаются в одном таргете. Зависимости подменяются через протоколы и внедрение, сеть через свой URLProtocol или заглушку клиента;
• UI: XCUITest, XCUIApplication, поиск элементов по accessibilityIdentifier, ожидание через waitForExistence(timeout:). Приложение запускается с launchArguments, по которым подставляет фейковый бэкенд. Таких тестов немного, только на ключевые сценарии: вход, оплата, онбординг;
• snapshot: чаще всего swift-snapshot-testing и assertSnapshot(of:as: .image). Ловят визуальные регрессии в вёрстке, тёмной теме, крупном шрифте Dynamic Type и локализациях.

Дальше про инфраструктуру: тест-планы .xctestplan с разными конфигурациями, параллельный запуск на симуляторах, xcodebuild test в CI, отчёт о покрытии. Назовите свои реальные цифры: сколько тестов, сколько длится прогон, что они поймали.

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

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

Пытаются покрыть UI-тестами всё подряд. Прогон растягивается на час, тесты мигают, и команда перестаёт им верить.

Ставят sleep() вместо ожидания элемента и потом не понимают, почему тест падает только в CI.

Записывают эталонные снимки на своём симуляторе, а CI запускает другую модель или версию iOS, и все snapshot-тесты краснеют. Модель симулятора и версия ОС фиксируются, а эталоны перезаписываются осознанно.