Комментарии 5
Спасибо за то что делитесь опытом!
А можете коротко описать как правильно применять TDD в мобильной разработке?
Я могу себе это предстваить когда речь идет о логике (создание той же модели, изменение ее состояний или покрытие API). Но неужели вы и для интерфейса сначала пишете UI тест который падает? Или вы проверяете генерацию UI в коде юнит-тестами?
Привет! Мы применяем TDD при разработке систем (аля view model), для интеграционных тестов между слоями и на сами сервисы. Вместо view model мы уже несколько лет практикуем однонаправленные архитектуры, такие как RxFeedback и Composable Architecture. Одним из плюсов стейт машин в том, что их удобно разрабатывать в парадигме TDD. В плане сервисов TDD полезен при разработке парсеров, конвертеров, форматеров и тд.
Тех радар не грузится. Возможно потому что я выбрал только strictly necessary cookies.
А расскажите, пожалуйста, если интерфейс вью с единственной функцией render(with: Model), то как рендерить ансихронные изменения данных?
Например, идут 2 параллельных запроса на бэк, приходит ответ и результаты обоих надо отобразить во вьюшке.
При разработке вью слоя, мы абстрагируемся от нижележащих слоев. Каждый вью компонент имеет свой ViewState, который задает конфигурацию для вью. Вью стейт описывает все возможные состояния вью. Функцию render дергается каждый раз когда меняется ViewState.
В твоем случае когда прилетит первый ответ он смапится во viewState, дернется render и экран перерисуется, прилетит второй ответ, получаем новый вью стейт и еще раз дергаем render.
4,5 года из жизни iOS-команды в пяти историях и одном техрадаре