У меня есть библиотека Java, которая использует некоторые вещи из API Android. Я хотел бы использовать Mockito для написания модульных тестов для этой библиотеки.
Есть ли способ, которым я могу это сделать?
Mockito не играет хорошо на VM Dalvik, см. это сообщение: Использование Mockito с виртуальной машиной Android
UPDATE:
С этого поста я открыл Robolectric, и у меня была возможность работать в Pivotal Labs и внести небольшой вклад в эту библиотеку. Я бы рекомендовал использовать это в рамках платформы Android/mockito. Кроме того, вы можете использовать Robolectric и Mockito, но теневые объекты в Robolectric делают Mockito ненужным для большинства случаев использования.
Проблема с попыткой unit test Android заключается в том, что в библиотеке Android, на которой вы строите, есть каждый метод, который вызывается либо для исключения исключений-заглушек, либо для возврата null. Если вы хотите протестировать свое приложение и хотите, чтобы какое-либо поведение Android вам не повезло, если вы не используете Robolectric, который перезаписывает байтовый код "на лету" при загрузке классов и вводит теневой объект, который имитирует поведение.
ОБНОВЛЕНИЕ 2:
Это было время, и все изменилось. Многие из классов Shadow в Robolectric были заменены настоящими классами Android. Настоящие Android-банки теперь используются, и Robolectric загружает классы Shadow для гораздо меньшего множества вещей. Это еще больше повод для использования Robolectric для тестирования Android.
После многого поиска в Google, я нашел ответ на этот здесь.
В основном это связано с использованием Robolectric модульной системы тестирования, которая перехватывает загрузку классов Android. Затем вы можете использовать Mockito (хотя в большинстве случаев это не обязательно) и запускать тесты на JVM!
Начиная с версии 1.9.5 (выпущен 3 июня 2012 года) вы можете использовать Mockito с Android. Для этого вам также потребуется dexmaker:
http://code.google.com/p/dexmaker/
Эта страница wiki описывает, как ее реализовать:
Взгляните на android-mock. Это основано на EasyMock 2.4 (так не так хорошо, как Mockito, но близко).
Он обходит ограничения DalvikVM, предварительно создавая макеты классов во время сборки, а не во время выполнения, а затем привязывая их к скомпилированному тестовому коду при развертывании на устройстве.
Там также насмешливая структура под названием Borachio, которую я не могу ручаться, но выглядит многообещающе (если вы счастливы пройти движения Scala для запуска на вашем устройстве).
Вы можете избежать этого, для всего, что не имеет никакого отношения к внутренним классам Android SDK.
Это то, что я делаю для своих Android-проектов (хотя я использую JMock2, а не Mockito).
У меня есть два тестовых проекта.
Первый использует JUnit4 и JMock2, которые я добавил в качестве зависимостей. Я тестирую все классы бизнес-логики, но я не могу проверить что-либо, что связано с Android (классы пользовательского интерфейса, SQLiteOpenHelper и т.д.). Если я попытаюсь использовать их в своих тестах, я получаю страшное исключение Stub!.
Второй тест для проверки пользовательского интерфейса, используя ActivityInstrumentationTestCase2 и Robotium.
Это может показаться большой работой и сложностью, но на самом деле это не так, и я считаю, что лучше их разделить. Тесты UI не являются "настоящими" модульными тестами, и они часто проверяют некоторые функции на нескольких устройствах. Если вы должным образом отделите свой уровень пользовательского интерфейса от своей бизнес-логики (и это разделение тестов заставит вас сделать это, в стиле TDD), тогда все будет хорошо и плавно.