Так и есть. Мое упущение, что не сделал должного акцента на том, что Clean Swift архитектура презентационного слоя. Впереди еще одна статья (на самом деле две), где сделаю должный акцент на этом моменте. Спасибо.
Класс HomeWorker содержит в себе методы только для сцены Home, не обязательно запросы в сеть. На «реальных проектах», запросы в сеть строятся в отдельном Network слое, а Worker'ы используются для «выноса» сложной/объемной реализации из Interactor'a для его разгрузки.
А если он мне понадобится в другом компоненте? Я тоже буду использовать его? Но тогда это будет зависимостью между двумя модулями/компонентами.
Нет, такой зависимости не должно быть. Для этого делаются глобальные Worker'ы и размещаются в директории Workers для переиспользования в разных сценах (в проекте CleanSwiftTests такой файл есть).
Как пример:
Вы имеете слой Network, который содержит в себе модели, ендпоинты и все необходимое, чтоб отправлять запросы и парсить ответы в модели. Далее, уже на Presentation слое (где у нас Clean Swift), мы через глобальные Worker'ы (если требуется использование на разных сценах) или локальные (если это только для одной сцены) выстраивает запрос (напрямую, если отсутствует отдельный слой Business Logic), обрабатываем его и возвращаем в Interactor через замыкание (или иный способ). Но это в том случае, если запрос нужно объемным способом сформировать или объемным способом обработать ответ. В противном случае, можно обращаться напрямую из Interactor'a (к Network или Business слою).
Несколько философский вопрос: а нам точно нужны такие подробности как был ли вызван имя_метода? Не совсем понятно, что нам это гарантирует. То что он вызвался не значит что все правильно?
В случае с Interactor'ом, мы проверяем, было ли обращение к Presenter'у и Worker'у.
— Вызывается Presenter, значит нет запутанной (тупиковой) логики в методе Interactor'a и данные уходят дальше.
— В случае с Worker'ом, мы подставляем тестовый дубль (Spy) для избежания реальных запросов в сеть при тестировании. Так же возвращаем шаблонные данные (вместо реальных из сети), для удобства тестирования работы логики Interactor'a. Так же, без подмены Worker'a, не будет вызываться замыкание, а значит мы не обработаем данные и не передадим их в Presenter. Но это уже от кейсов зависит.
А еще мне кажется что в данном случаем мы тестирует «техническую» реализацию составляющую, а не «логическую». Что я имею ввиду, мы проверяем не «правильность» работы а «путь» выполнения работы. На простом примере, мы должны валидировать имейл. Вместо того чтоб, проверять конечный результат валидный/невалидный, мы проверяем как мы это делаем(регялярки или еще что-то).
Да, конечно, мы должны проверять результат. Основная задача статьи — показать как это делается с компонентами в Clean Swift, как заменять объекты тестовыми дублями, для чего и к чему это приводит. В полном примере приложения (на GitHub), есть тестирование Presenter'a, где проверяется правильность сортировки и т.д.
Спасибо за комментарий! По сути ViewController остается максимально «тупым», вся логика переходов и передачи данных выносится в Router (я постарался подробно это описать в следующей статье). Сам ViewController только и умеет, что брать данные и отправлять их в Interactor на обработку (помимо получения/обновления данных View).
Конечно, в крупных проектах все сильно разрастется на любой архитектуре. Для этого сцены можно (даже нужно) бить на контейнеры. По крайней мере в данный момент с разрастанием не сталкивался, но дальше будет видно :)
Да, все верно, в команде нужно заранее обговорить, какой тип перехода будет использоваться. В статье я показал «как можно сделать», а так нужно для себя решить «как будет».
Добавил в опрос пункт "Преподавал в прошлом", спасибо за рекомендацию)
Вроде, все ссылки живы. Попробуйте ещё раз
Нет, такой зависимости не должно быть. Для этого делаются глобальные Worker'ы и размещаются в директории Workers для переиспользования в разных сценах (в проекте CleanSwiftTests такой файл есть).
Как пример:
Вы имеете слой Network, который содержит в себе модели, ендпоинты и все необходимое, чтоб отправлять запросы и парсить ответы в модели. Далее, уже на Presentation слое (где у нас Clean Swift), мы через глобальные Worker'ы (если требуется использование на разных сценах) или локальные (если это только для одной сцены) выстраивает запрос (напрямую, если отсутствует отдельный слой Business Logic), обрабатываем его и возвращаем в Interactor через замыкание (или иный способ). Но это в том случае, если запрос нужно объемным способом сформировать или объемным способом обработать ответ. В противном случае, можно обращаться напрямую из Interactor'a (к Network или Business слою).
В случае с Interactor'ом, мы проверяем, было ли обращение к Presenter'у и Worker'у.
— Вызывается Presenter, значит нет запутанной (тупиковой) логики в методе Interactor'a и данные уходят дальше.
— В случае с Worker'ом, мы подставляем тестовый дубль (Spy) для избежания реальных запросов в сеть при тестировании. Так же возвращаем шаблонные данные (вместо реальных из сети), для удобства тестирования работы логики Interactor'a. Так же, без подмены Worker'a, не будет вызываться замыкание, а значит мы не обработаем данные и не передадим их в Presenter. Но это уже от кейсов зависит.
Да, конечно, мы должны проверять результат. Основная задача статьи — показать как это делается с компонентами в Clean Swift, как заменять объекты тестовыми дублями, для чего и к чему это приводит. В полном примере приложения (на GitHub), есть тестирование Presenter'a, где проверяется правильность сортировки и т.д.
Конечно, в крупных проектах все сильно разрастется на любой архитектуре. Для этого сцены можно (даже нужно) бить на контейнеры. По крайней мере в данный момент с разрастанием не сталкивался, но дальше будет видно :)