Как тестировать форму логина

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

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

Как отвечать

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

• юнит-тесты: валидатор и view model формы. Состояния idle, loading, error, success, неактивная кнопка при пустых полях, текст ошибки для 401, 429 и отсутствия сети. Сервис авторизации подставляется через протокол, писать можно на XCTest или на Swift Testing;
• сеть: подкласс URLProtocol перехватывает запросы URLSession и отдаёт заготовленные ответы, так проверяются разбор ошибок и таймаут без сервера;
• UI-тесты на XCUITest: элементы ищутся по accessibilityIdentifier, а через launchArguments или launchEnvironment приложение переключается на стаб вместо API.

Что проверить именно на iOS:

• безопасность: поле пароля с isSecureTextEntry, токен лежит в Keychain, а не в UserDefaults, пароль не попадает в логи;
• автозаполнение: textContentType равен .username и .password, для кода из SMS .oneTimeCode. Чтобы система подставляла сохранённые пароли для вашего домена, нужен associated domain webcredentials;
• клавиатура: Return переводит фокус на следующее поле, клавиатура не перекрывает кнопку входа на маленьком экране;
• доступность: подписи для VoiceOver, крупный шрифт Dynamic Type не ломает раскладку;
• жизненный цикл: сворачивание во время запроса, двойной тап не шлёт два запроса, выход из аккаунта чистит Keychain.

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

Ограничиваются проверкой формата email. Поведение при ошибках сервера и без сети важнее регулярки.

Гоняют UI-тесты против настоящего бэкенда. Тесты медленные, зависят от стенда и падают без причины в коде.

Хранят токен в UserDefaults и не проверяют, что после выхода он удалён. Учтите и обратное: запись в Keychain переживает удаление приложения, и после переустановки пользователь может оказаться залогинен.