Android: модульное тестирование приложений Android с Robolectric и Mockito

Question

У меня есть библиотека Java, которая использует несколько вещей из API-интерфейсов Android.Я хотел бы использовать Mockito для написания модульных тестов для этой библиотеки.

Есть ли способ, которым я могу пойти по этому поводу?

Mockito плохо играет на виртуальной машине Dalvik, см. Этот пост: Использование Mockito с виртуальной машиной Android

ОБНОВЛЕНИЕ:

С этого поста я открыл для себя Robolectric, и у меня была возможность поработать в Pivotal Labs и внести небольшой вклад в эту библиотеку.Я бы порекомендовал использовать это поверх среды тестирования Android / mockito.Кроме того, вы можете свободно использовать Robolectric AND Mockito, но теневые объекты в Robolectric делают Mockito ненужным для большинства случаев использования.

Проблема с попыткой модульного тестирования Android состоит в том, что библиотека Android, на которой вы строите, имееткаждый метод заглушается, чтобы генерировать исключение заглушки или возвращать ноль.Если вы хотите протестировать свое приложение и хотите получить какое-либо поведение Android, вам не повезло, если только вы не используете Robolectric, который перезаписывает байт-код на лету при загрузке классов и внедряет теневой объект, имитирующий поведение.

ОБНОВЛЕНИЕ 2:

Прошло много времени, и все изменилось.Многие из классов Shadow в Robolectric были заменены настоящими классами Android.Теперь используются настоящие банки Android, и Robolectric загружает классы Shadow только для гораздо меньшего набора вещей.Это еще одна причина использовать Robolectric для тестирования Android.

Answer 1

После долгих поисков, я наткнулся на ответ для этого здесь .

В основном это связано с использованием Robolectric инфраструктуры для модульного тестирования, которая перехватывает загрузкуклассы Android.Затем вы можете использовать Mockito (хотя в большинстве случаев это не нужно) и запускать свои тесты на JVM!

Answer 2

Начиная с версии 1.9.5 (выпущена 3 июня 2012 г.) вы можете использовать Mockito с Android. Для этого вам также потребуется dexmaker:

http://code.google.com/p/dexmaker/

На этой вики-странице описано, как это реализовать:

http://code.google.com/p/dexmaker/wiki/Mockito

Answer 3

Этого можно избежать, поскольку все, что не имеет ничего общего с внутренними классами Android SDK. Это то, что я делаю для своих проектов Android (хотя я использую JMock2, а не Mockito).

У меня есть два тестовых проекта.

• Первый использует JUnit4 и JMock2, которые я добавил в качестве зависимостей. Я тестирую все классы "бизнес-логики", но не могу протестировать ничего, что связано с Android (классы пользовательского интерфейса, SQLiteOpenHelper и т. Д.). Если я пытаюсь использовать их в своих тестах, я получаю исключение Stub! .

• Второй для проверки пользовательского интерфейса, используя ActivityInstrumentationTestCase2 и Robotium.

Это может показаться большой работой и сложной, но на самом деле это не так, и я действительно думаю, что лучше их разделить. Тесты пользовательского интерфейса не являются «настоящими» юнит-тестами, и они часто тестируют некоторые функции на нескольких юнитах. Если вы правильно отделите свой слой пользовательского интерфейса от своей бизнес-логики (и это разделение тестов заставит вас сделать это в стиле TDD), тогда все будет хорошо и гладко.

Answer 4

Взгляните на android-mock .Он основан на EasyMock 2.4 (так что не так хорошо, как Mockito, но близко).

Он позволяет обойти ограничения DalvikVM, предварительно сгенерировав фиктивные классы во время сборки, а не во время выполнения, а затем добавив в них скомпилированный тестовый код при развертывании на устройстве.

Естьтакже насмешливый фреймворк под названием Borachio , за который я не могу ручаться, но выглядит многообещающе (если вы счастливы пройти через все шаги по запуску Scala на вашем устройстве).