- Я использую ActivityInstrumentationTestCase2 в случае действий для TDD (или, скорее, BDD), и пишу обычные модульные тесты для всей логики. Это также помогает мне отделить логику от действий.
- Мобильные приложения по своей природе ориентированы на пользовательский интерфейс. Поэтому это не
имеет смысл макетировать пользовательский интерфейс, даже если он заставляет модульный тест выглядеть
как функциональный тест.
- Для добавления дополнений к намерениям вы можете установить собственное намерение для теста или сделать это для всех тестов, переопределив настройку.
- Моды дают много проблем на Android, поэтому я использую заглушки.
Пример приведен ниже. Активность показывает Hello World, когда вы нажимаете кнопку -
public class HelloWorldActivityTest extends
ActivityInstrumentationTestCase2<HelloWorldActivity> {
private HelloWorld activity;
public HelloWorldActivityTest() {
super(HelloWorldActivityTest.class);
}
public void testShouldRenderGreetingOnButtonClick() {
activity = this.getActivity();
Button button = (Button) activity.findViewById(R.id.btn_greet);
TouchUtils.clickView(this, button);
assertEquals("Hello World!",
((TextView) activity.findViewById(android.R.id.greeting_text))
.getText());
}
}
РЕДАКТИРОВАТЬ: С тех пор, как я опубликовал ответ, все изменилось. У Mockito теперь достаточно хорошая поддержка для Android. А для тестов мы перешли от ActivityInstrumentationTestCase2 к Robolectric, просто для того, чтобы задействовать явную скорость JVM на этапе разработки. Android Testing Framework отлично подходит для интеграции и функционального тестирования, но не для модульных тестов.