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

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

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

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

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

Ваш интеграционный тест должен быть написан как тестовый класс JUnit 4. Дополнительные сведения о создании классов тестов JUnit 4 и использовании утверждений JUnit 4 см. в разделе Создание класса локального модульного теста .

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

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

Котлин 


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

Ява 


@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() . Ваши тесты должны подтвердить, что все эти методы работают.
  • Проверьте бизнес-логику . Если поставщик контента реализует бизнес-логику, вам следует ее протестировать. Бизнес-логика включает обработку недопустимых значений, финансовые или арифметические вычисления, удаление или объединение дубликатов.