Как стать автором
Обновить

HandsAppMVP: iOS-архитектура для студии аутсорс разработки

Время на прочтение 5 мин
Количество просмотров 4.5K
Всего голосов 10: ↑9 и ↓1 +8
Комментарии 6

Комментарии 6

По поводу плохой тестируемости реактивного кода не соглашусь. На RayWenderlich есть классная статья, а также недавно подъехал перевод этой статьи на хабре.
Реактивный код вполне себе хорошо и удобно тестируется. Возможно, не так удобно как слои в VIPER, но в 2016 году, когда я писал вот эту статью, было гораздо неудобней.
Да, статья на raywenderlich действительно полезная, спасибо!
RxTest позволяет довольно просто писать тесты для реактивных объектов. Но как ни крути это сторонний фреймворк, для его использования необходимо хорошо понимать тонкости rx и строго заключать всю тестируемую логику в реактивных операторах. Если этого не делать (что лично у меня на практике сплошь и рядом встречалось), то придется смешивать тесты через RxTest и обыкновенные unit-тесты открытых методов.
Мы не стали здесь раскрывать эту тему, потому что для нее нужна как минимум отдельная статья)
Спасибо за ответ!

Rx уже стал стандартом де-факто в разработке — сложно найти проекты, которые его не используют, поэтому он имеет огромное комьюнити, которое его поддерживает в актуальном состоянии. Я к тому, что хоть это действительно сторонний фреммворк, он имеет огромный вес на рынке и его понимание прямо сейчас является необходимостью в большинстве вакансий.

А зачем такое жесткое разделение на реактивные и нереактивные тесты? Понятно что реактивная и нереактивная логика всегда будут рядом, т.к. обмазываться Rx'ом по всему проекту практика достаточно странная. Что вам мешает это смешивать?
Нвпример, у нас в команде используется RxTest, RxBlocking, SwiftyMocky для генерации моков и тестирования вызовов функций в моках, iOSSnapshotTestCase тесты от убера, ну и родные UI тесты и XCTest. Итого 6 тестов различных видов, которые очень сильно автоматизируют нашу работу по созданию моков и работу QA при регрессе/смоках приложений. Все эти тесты вполне себе хорошо живут рядом и не мешают друг другу
Спасибо за статью!
Не считаете ли вы, протоколы ViewInput и ViewOutput излишни, так как связь между View м Presenter слишком сильная? Мне не удалось придумать пример, когда бы пригодилось отсутствие явной зависимости между Presenter и View. Можете привести пример когда это помогло?
Мы уделяем достаточно внимания тестированию логики представления, а для этого необходима возможность вырвать презентер из контекста всех его зависимостей и заменить их тестовыми дублёрами. Использование зависимостей на абстракции, в частности — протоколов ViewInput и ViewOutput, позволяет это сделать. Пример тестов можно посмотреть в нашем демо-проекте — пример.

Если не писать тесты, то вполне можно и не использовать эти протоколы и ссылаться на презентер явно. Все идет от потребностей)
Помимо тестов такая система неплохо помогает, если есть весьма похожие внешне экраны с практически или совершенно разной логикой: ViewInput/Output протоколы позволяют легко и непринужденно подсунуть к готовой View другой Presenter с новой логикой.
В качестве примера, из последнего, когда такой прием применял — экран карты неких объектов. В одном кейсе экран представлял собой просто View с минимум логики, где даже запрос не выполнялся, в другом — самостоятельный полноценный экран -> View одна и она переиспользуется, просто к ней подсовывается в каждом случае свой Presenter
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории