Юнит тесты на RxSwift

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

На данный момент существуют различные виды тестов. Помимо тестирования цельного готового продукта не менее важны и модульные тесты. Преимущество данного вида тестирования заключается в том, что появляется возможность проверить работоспособность каждого модуля кода, а также облегчается обнаружение и устранение ошибок на раннем этапе. Более того, это значительно сокращает расходы на разработку, поскольку стоимость обнаружения багов на разных этапах существенно отличается. Если обнаружить ошибку при модульном тесте, стоимость будет небольшой. А при её обнаружении на этапе релиза продукта стоимость возрастёт в несколько раз.

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

Описание архитектуры приложения

Наше приложение построено на архитектуре MVVM с использованием контроллеров. Приложение разделяется на логические модули, каждый состоит из ViewModel, Model, ViewController и координаторов. ViewModel реализует паттерн StateMachine. Связь между компонентами ViewModel и ViewController реализуется с помощью библиотеки Reactor Kit. Для биндинга ViewModel и ViewController используется RxSwift.

Постановка проблемы

Поскольку в приложении используются реактивные библиотеки, реализовать модульное тестирование было проблематично. Реактивность сложно проверить модульными тестами, так как код является асинхронным.

Решение

По этой причине для тестирования ViewModel было решено использовать библиотеку RxBlocking. У неё имеется два основных преимущества.

Во-первых, с помощью данной библиотеки определённый реактивный участок кода можно сделать последовательным. Функция будет ожидать, пока она получит какое-то значение от наблюдаемой переменной (observable). В данном случае – state ViewModel. Библиотека позволяет фильтровать получаемые сигналы. Можно пропустить, добавить задержку, завершить тест по тайм-ауту, если сигнал не был получен в течение какого-то времени. Модульные тесты должны выполняться быстро, поэтому чтобы не ожидать сигнала бесконечно, мы можем по тайм-ауту не пройти тест. Например, если в течение пяти секунд не был получен сигнал, то тест считается неудачным.

Во-вторых, ViewModel использует множество сервисов, которые обращаются к базам данных и внешним API. Запросы к БД и API могут занимать продолжительное время, которое зависит от многих факторов (например, скорость и наличие интернет-соединения, количество записей в базе данных). При этом одно из условий модульного тестирования заключается в том, что в одинаковых условиях тесты должны выдавать одинаковый результат. Они не должны зависеть от условий, которые мы не контролируем, поэтому в юнит тестировании используются фейковые серверы, или так называемые «заглушки». Они подставляют заранее предопределённый набор данных, на которых и проводятся тесты.

Однако, к недостаткам модульного тестирования можно отнести невозможность выявления ошибок на других уровнях. Как видно из названия, unit testing может проверять функциональность лишь отдельных модулей кода, а поэтому ошибки интеграции и другие системные ошибки, например, в производительности, остаются непроверенными. Поэтому следует применять юнит тесты вместе с другими видами тестирования.

Вывод

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