Тестирование поставщиков контента

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

Создание интеграционных тестов для поставщиков контента

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

Чтобы протестировать поставщика контента отдельно, используйте класс ProviderTestCase2. Этот класс позволяет использовать классы макет-объектов Android, такие как IsolatedContext и MockContentResolver, для доступа к информации о файлах и базах данных, не затрагивая фактические пользовательские данные.

Интеграционный тест должен быть написан как тестовый класс JUnit 4. Подробнее о том, как создавать тестовые классы JUnit 4 и использовать утверждения JUnit 4, рассказывается в статье Как создать локальный класс модульного тестирования.

Чтобы создать интеграционный тест для поставщика контента, выполните следующие действия:

  1. Создайте тестовый класс как подкласс ProviderTestCase2.
  2. Укажите класс AndroidJUnitRunner, который предоставляет AndroidX Test, в качестве средства запуска тестов по умолчанию.
  3. Задайте объект Context из класса ApplicationProvider. Пример приведен ниже.

Kotlin

@Throws(Exception::class)
override fun setUp() {
  super.setUp()
  context = ApplicationProvider.getApplicationContext<Context>()
}

Java

@Override
protected void setUp() throws Exception {
  super.setUp();
  setContext(ApplicationProvider.getApplicationContext());
}

Как работает ProviderTestCase2

Вы тестируете поставщика с подклассом ProviderTestCase2. Этот базовый класс расширяет AndroidTestCase, поэтому он предоставляет фреймворк тестирования JUnit, а также методы тестирования разрешений приложения, характерные для Android. Самая важная особенность этого класса – его инициализация, которая создает изолированную тестовую среду.

Инициализация

Инициализация выполняется в конструкторе для ProviderTestCase2, который подклассы вызывают в своих конструкторах. Конструктор ProviderTestCase2 создает объект IsolatedContext, который позволяет выполнять операции с файлами и базами данных, но блокирует другие взаимодействия с системой Android. Операции с файлами и базами данных выполняются в каталоге, который является локальным для устройства или эмулятора и имеет специальный префикс.

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

Наконец, конструктор создает экземпляр тестируемого поставщика. Это обычный объект ContentProvider, но он получает всю информацию о среде из IsolatedContext, поэтому может работать только в изолированной тестовой среде. Все тесты, выполненные в классе тестового примера, выполняются для этого изолированного объекта.

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

Что тестировать

Ниже приведены рекомендации по тестированию поставщиков контента.

  • Тестируйте с помощью методов распознавателя. Хотя вы можете создать экземпляр объекта поставщика в ProviderTestCase2, всегда тестируйте с помощью объекта распознавателя, используя соответствующий URI. Это позволит вам протестировать поставщика, выполнив то же взаимодействие, которое использовало бы обычное приложение.
  • Тестируйте общедоступный поставщик как контракт. Если вы хотите, чтобы поставщик был общедоступным и другие приложения могли его использовать, тестируйте его как контракт. Вот несколько примеров:
    • Протестируйте константы, которые ваш поставщик предоставляет в открытом доступе. Например, найдите константы, которые ссылаются на названия столбцов в одной из таблиц данных поставщика. Это всегда должны быть константы, публично определенные поставщиком.
    • Протестируйте все URI, которые предлагает ваш поставщик. Поставщик может предлагать несколько URI, каждый из которых относится к разным аспектам данных.
    • Протестируйте недействительные URI. В модульных тестах следует намеренно вызывать поставщика с недопустимым URI и искать ошибки. Рекомендуется настроить поставщик так, чтобы он выдавал ошибку IllegalArgumentException при получении недопустимых URI.
  • Протестируйте стандартные взаимодействия с поставщиком. Большинство поставщиков предлагают шесть методов доступа: query(), insert(), delete(), update(), getType() и onCreate(). В ходе тестирования необходимо убедиться, что все эти методы работают.
  • Протестируйте бизнес-логику. Если поставщик контента реализует бизнес-логику, ее необходимо протестировать. Бизнес-логика включает обработку недопустимых значений, финансовые или арифметические расчеты, удаление или объединение дубликатов.