Осваиваем ViewModel в Android: «можно» и «нельзя» — Часть 5

Это пятая часть нашей серии «Освоение ViewModel в Android», в которой мы погружаемся в изучение основных правил и запретов, способных повысить ваши навыки разработки под Android. Мы уже рассмотрели несколько советов по улучшению производительности и качества кода во ViewModel, которые стали неотъемлемой частью современных Android-приложений.

В предыдущих частях мы уже обсуждали:

1. Избегайте инициализации состояния в блоке init{}.
2. Избегайте раскрытия мутабельных состояний.
3. Используйте update{} при использовании MutableStateFlows.
4. Старайтесь не импортировать зависимости Android во ViewModel
5. Лениво внедряйте зависимости в конструктор
6. Примите более реактивное и менее императивное программирование
7. Избегайте инициализации ViewModel из внешнего мира

В этой статье мы рассмотрим:

8. Избегайте жесткого прописывания диспетчеров корутинов
9. Проводите модульное тестирование своих ViewModel
10. Избегайте раскрытия suspended функций

8. Избегайте жесткого прописывания диспетчеров корутинов

Когда вы имеете дело с корутинами в вашей ViewModel, жесткое прописывание диспетчеров, таких как Dispatchers.IO или Dispatchers.Default, может показаться удобным, но это может привести к связанному и менее тестируемому коду.

Проблема с жестким хардкодом диспетчеров

Жесткое прописывание диспетчеров непосредственно в вашей ViewModel может затруднить тестирование и снизить гибкость. Например, во время тестирования вы можете захотеть управлять поведением потоков, что становится затруднительным при использовании жестко зазакодированных диспетчеров.

Рекомендуемый подход

Инжектируйте диспетчеры через конструктор или используйте фреймворк для инъекции зависимостей, например Hilt или Dagger. Это не только сделает вашу ViewModel более гибкой, но и упростит тестирование:

class MyViewModel(
    private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO
) : ViewModel() {

  private fun loadData() {
     viewModelScope.launch(ioDispatcher) {
       // Your coroutine code here
     }
  }
}

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

Для примера посмотрите на этот код.

9. Проводите модульное тестирование своих ViewModel

Юнит-тестирование необходимо для того, чтобы убедиться, что ваши ViewModel ведут себя так, как ожидается. Без надлежащих тестов вы рискуете внедрить ошибки, которые можно было бы отловить на ранней стадии.

Проблемы тестирования

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

Лучшие практики для тестирования ViewModel

• Используйте TestCoroutineDispatcher, чтобы контролировать выполнение корутин и тестировать асинхронный код синхронно
• Предпочитайте тестировать ViewModels как не-Android тест (используйте папку test вместо androidTest)
• Избегайте использования runBlocking{} для тестирования приостановленных функций, вместо этого используйте runTest{} из coroutines-test
• Избегайте ручного выбора значений из StateFlows, вместо этого используйте Turbine
• Для тестирования Flow используйте Turbine
• Отдавайте предпочтение фейкам перед моками

10. Избегайте раскрытия suspended функций

Хотя suspend функции упрощают асинхронное программирование в Kotlin, их раскрытие непосредственно из вашей ViewModel может привести к неправильному использованию и повышенной сложности.

Почему это проблематично

Выставление suspend функций может привести к неправильному управлению потоками или событиями жизненного цикла, что приведет к ошибкам или сбоям.

Лучший способ

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

Заключение

Освоение ViewModel в разработке под Android имеет решающее значение для создания надежных, эффективных и поддерживаемых приложений. В этой серии статей мы рассмотрели полный набор лучших практик для повышения качества кода и производительности приложений.

Источник