Как Context влияет на тестируемость класса

Контекст и тестируемость в Android

В Android-разработке Context — это фундаментальный абстрактный класс, предоставляющий доступ к ресурсам приложения, системным сервисам, файловой структуре и другим глобальным элементам среды выполнения. Прямая зависимость класса от Context (особенно от Activity или Application) — одна из наиболее частых причин проблем с тестируемостью.

Почему Context усложняет тестирование

1. Сильная связь с Android Framework: Классы, использующие Context напрямую, становятся тесно связанными с платформой Android. Поскольку юнит-тесты выполняются на JVM (без Android Runtime), любые попытки создать или использовать реальный Context в тестах приводят к RuntimeException или необходимости в инструментах вроде Robolectric, что замедляет тесты и усложняет их поддержку.

2. Сложность изоляции: Класс, зависящий от Context, часто использует его для множества задач: доступ к Resources, SharedPreferences, PackageManager, запуск Activity, работа с LayoutInflater. Это превращает его в "God Object", чье поведение сложно проконтролировать в тестах.

   // Проблемный класс: сильная связь с Context
   class UserPrefsManager(private val context: Context) {
       fun saveUserName(name: String) {
           context.getSharedPreferences("app", Context.MODE_PRIVATE)
               .edit()
               .putString("user_name", name)
               .apply()
       }
   }
   

   Для тестирования UserPrefsManager потребуется либо настоящий Context (что невозможно в чистых юнит-тестах), либо его mock/stub со сложной настройкой.

Стратегии улучшения тестируемости

1. Инъекция зависимостей (Dependency Injection)

Внедрять не сам Context, а конкретные сервисы, которые он предоставляет. Это делает зависимости явными и позволяет заменять их в тестах.

// Улучшенная версия: зависимость от интерфейса
interface PreferencesStorage {
    fun saveString(key: String, value: String)
    fun getString(key: String): String?
}

class SharedPrefsStorage(private val sharedPreferences: SharedPreferences) : PreferencesStorage {
    override fun saveString(key: String, value: String) {
        sharedPreferences.edit().putString(key, value).apply()
    }
    override fun getString(key: String): String? = sharedPreferences.getString(key, null)
}

class UserPrefsManager(private val storage: PreferencesStorage) { // Context больше не нужен!
    fun saveUserName(name: String) {
        storage.saveString("user_name", name)
    }
}

Теперь класс можно протестировать, передав FakePreferencesStorage:

class UserPrefsManagerTest {
    @Test
    fun `saveUserName stores data in storage`() {
        val fakeStorage = FakePreferencesStorage()
        val manager = UserPrefsManager(fakeStorage)
        
        manager.saveUserName("John")
        
        assertEquals("John", fakeStorage.getString("user_name"))
    }
}

2. Architecture Components: ViewModel и LiveData

ViewModel специально разработан для отделения логики от Context. Он не содержит ссылок на UI-компоненты и легко тестируется.

class UserProfileViewModel(
    private val loadUserUseCase: LoadUserUseCase // UseCase, не зависящий от Context
) : ViewModel() {
    private val _userData = MutableLiveData<User>()
    val userData: LiveData<User> = _userData
    
    fun loadUser(userId: String) {
        viewModelScope.launch {
            _userData.value = loadUserUseCase.execute(userId)
        }
    }
}

3. Использование Application Context вместо Activity Context

Если Context действительно необходим (например, для доступа к ресурсам), следует использовать Application Context, который проще mock-ировать и он имеет более предсказуемый lifecycle.

4. Паттерн "Wrapper" или "Adapter"

Создание обёрток вокруг Android-специфичных компонентов:

interface ResourceProvider {
    fun getString(@StringRes resId: Int): String
    fun getColor(@ColorRes resId: Int): Int
}

class AndroidResourceProvider(private val context: Context) : ResourceProvider {
    override fun getString(resId: Int): String = context.getString(resId)
    override fun getColor(resId: Int): Int = ContextCompat.getColor(context, resId)
}

Вывод

Прямая зависимость от Context снижает тестируемость, создавая coupling с Android Framework. Ключевые принципы улучшения ситуации:

• Инъекция зависимостей вместо прямого использования Context
• Зависимость от абстракций, а не от конкретных реализаций
• Разделение ответственности: логика работы с данными отделяется от логики работы с UI
• Использование архитектурных паттернов (MVVM, MVI) с чётким разделением слоёв

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