TDD и VIPER

Кратко о том что такое TDD

TDD - разработка через тестирование. Предполагается, что в начале пишутся тесты, потом реализация. В случае, если мы закрываем реальные классы протоколами, они идут первыми. После того, как все компоненты написаны - они могут быть интегрированы.

Благодаря такому подходу достигается полное описание ожидаемого поведения класса в тестах. Тесты могут служить в качестве примеров использования класса. Также TDD позволяет нам непредвзято посмотреть на класс с точки зрения пользователя данного класса до его написания.

Более подробно тема TDD была разобрана в статье Андрея Резанова.

VIPER

Обычно разделения на основные слои приложения достаточно для того, чтобы довольно неплохо протестировать сервисный и Core слой, но при наличии "толстого" VC возникают проблемы в тестировании Presentation слоя, и потому многие оставляют его без тестов. Давайте разберемся как VIPER-модули могут помочь нам в покрытии View тестами.

Общим подходом для тестирования является следующий: Окружаем объект тестируемого класса протокол-моками зависимостей. Вызываем методы интерфейса/манипулируем свойствами, проверяем вызовы методов моков.

Тестирование View

Существует некоторое количество библиотек, помогающих в тестировании UI слоя, а с недавних пор у нас появились еще и UI-тесты. Достаточно ли этого для полноценного покрытия View? На мой взгляд - нет.

UI-тесты могут служить неплохим способом написания acceptance, или приемочных тестов. В роли черного ящика выступает все боевое приложение, и мы через интерфейс приложения пытаемся получить тот или иной результат, опять же на интерфейсе.

Проблема с UI-тестами в том, что в случае перегруженного VC весь View является для нас черным ящиком с множеством состояний, и для тестирования необходимо слишком большое количество тестов.

Чем нам тут может помочь VIPER? Из VC выносится логика по подготовке и представлению данных в Presenter. Соответственно на View ложится ответственность лишь за обработку и прокидывание событий в Presenter, а также за отображение UI. Отдельно необходимо заострить внимание на том, что View является не обязательно UI, это класс через который происходит взаимодействие внешнего мира с модулем. Что это означает для нас? Это означает, что IBOutlet и IBAction необходимо делать публичными. Как итог мы получаем возможность протестировать всевозможные нажатия, заполнение полей и прочее без симуляции нажатий, поиска нужных кнопочек по тексту на них и прочих ненадежных вещей.

Отдельно замечу, что Presenter общается с View через протокол.

Подытожим, выделив 2 основных вида тестов:

• Взаимодействуем с IBOutlet/вызываем IBAction -> проверяем, что были вызваны соответствующием методы мока Presenter
• Вызываем методы протокола, через который общается Presenter -> проверяем, что меняются IBOutlet/View

Отдельно можно выделить тестирование методов жизненного цикла VC/V, на которые нам так или иначе необходимо ориентироваться, т.к. зачастую Presenter не может начинать настройку View до viewDidLoad или viewWillAppear.

Тестирование Router

Методы роутера вызываются когда необходимо совершить переход из текущего VC. Соответственно тестами покрываются методы переходов/закрытия текущего контроллера. Тестируем вызовы всевозможных аниматоров переходов.

Тестирование Interactor'ов

Interactor является связующим звеном в работе с всевозможными сервисами. Именно через него работа идет работа со Storage, в нем создаются PONSO-объекты.

Но большинство тестов касаются проверки вызовов одних сервисов в зависимости от ответов других.

Тестирование Presenter

Presenter можно назвать связающим звеном модуля, т.к. в ним происходит проксирование запросов от одной части модуля к другой. Тесты на подобную передачу составляют львиную долю от тестов Presenter.

Отдельно замечу, что Presenter является входной точкой для модуля, именно в него передаются данные с предыдущего контроллера. На это опять же необходимо писать тесты.

Presenter является местом, где скорее всего будет максимальное число свитчей и ветвлений. Это также необходимо учитывать, и на вход подавать все возможные принципиально отличающиеся друг от друга комбинации значений.

Тестирование Assembly

Assembly настраивает зависимости компонентов модуля. Его тесты ответственны за то, чтобы проверять, что модуль состоит из правильных частей и все зависимости заполнены.

К счастью, при строгой структуре модуля, данные тесты могут быть созданы автоматически.