Как проверить правильность передачи данных на сетевой уровень
Что проверяют
Умеете ли вы увидеть, что приложение на самом деле отправляет в сеть, и закрепить это тестами, а не судить по ответу сервера. Следом обычно спрашивают, как тестировать сетевой слой без живого бэкенда.
Как отвечать
Разделите проверку на ручную и автоматическую.
Ручная:
- Proxyman, Charles или mitmproxy: на устройство ставится корневой сертификат прокси, и в «Настройки > Основные > Об этом устройстве > Доверие сертификатам» ему включается полное доверие. После этого видны метод, URL, заголовки, тело и коды ответа;
- Instruments: инструмент HTTP Traffic показывает запросы приложения без стороннего прокси;
- Wireshark: полезен на уровне TCP и TLS, но содержимое HTTPS без ключей не покажет.
Автоматическая: подменяете транспорт. Подкласс URLProtocol, зарегистрированный в URLSessionConfiguration.protocolClasses, перехватывает запросы в юнит-тестах, и вы проверяете собранный URLRequest: путь, query, заголовки, Content-Type, тело после JSONEncoder. Альтернатива: сетевой клиент за протоколом и мок на его месте.
Что сверять: кодирование дат и ключей (по умолчанию JSONEncoder пишет Date числом секунд от 1 января 2001 года, а сервер обычно ждёт ISO 8601), экранирование query, обработку nil-полей, идемпотентность повторов. Для загрузки файлов имеет смысл сравнить SHA-256 на клиенте и сервере, а целостность самих пакетов уже обеспечивают TCP и TLS.
Где спотыкаются
Считают код 200 доказательством, что данные ушли правильно. Сервер мог принять запрос и молча проигнорировать неизвестное поле.
В перехватчике на URLProtocol читают request.httpBody и получают nil: к этому моменту URLSession превращает тело в httpBodyStream, читать надо его.
Не могут поймать трафик через прокси и не вспоминают про SSL pinning. В отладочной сборке его отключают или добавляют ключ прокси в список закреплённых.