Robotium. В наборе тестов каждый следующий тест зависит от предыдущего теста

У меня есть несколько тестов пользовательского интерфейса. Когда я запускаю один тест, все в порядке. Но если я запускаю пакет из них (как часть сборки CI), тест завершится неудачно, потому что тесты, которые сначала меняют состояние приложения, а на следующие тесты влияют эти изменения. (Поскольку приложение не убивается).

Я попробовал getActivity().finish() в tearDown().
Пробовал solo.finalize(), который делает то же самое на самом деле.

Есть ли способ иметь новое приложение в начале каждого тестового прогона? (Использование Robotium).
И есть ли способ программно убить приложение в конце теста?
Я использую ActivityInstrumentationTestCase2 с Robotium

Ответ 1

Почему бы не добавить adhoc способ "убить" приложение, в зависимости от конкретного приложения, которое вы тестируете? Например, в зависимости от глубины активности вашего приложения, "нажмите 3 раза" или что-то подобное может быть достаточно хорошим.

Вы можете добавить, что в методе tearDown ваших тестов суперкласс, чтобы он запускался после каждого из ваших тестов.

Вы должны думать о своих тестах Robotium не как обычные модульные тесты (их нет!), а как пользовательские случаи, приемочные тесты. Поэтому, если вы хотите закрыть приложение, сделайте в этих тестах то, что вы ожидаете от пользователя, чтобы закрыть приложение.

Ответ 2

Или просто добавьте solo.finishOpenedActivities();

Ответ 3

Не совсем уверен в характере вашего набора тестов, но у меня были проблемы с запуском нескольких тестов "нового старта" и зависанием второго теста. Моя проблема связана с порожденными действиями и была решена путем запуска активности с FLAG_ACTIVITY_CLEAR_TOP - конечно, это очищает стек, но я думаю, что вы хотите?

    Intent i = new Intent();
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    setActivityIntent(i);
    solo = new Solo(getInstrumentation(), getActivity());

Ответ 4

Причины проблемы:

В API нет API-интерфейса, чтобы получить список всех действий в стеке.
Обходной путь для (1) заключается в том, чтобы использовать ActivityMonitor для отслеживания каждого запускающегося Действия.
Robotium использует обходное решение, но он устанавливает свой ActivityMonitor ПОСЛЕ того, как ваш тестовый пример ActivityInstrumentationTestCase2 начинает свою деятельность, то есть:
```
Activity activity = getActivity();
Solo solo = new Solo(getInstrumentation(), activity);
```

Если ваш тест активности - это переадресация, то, скорее всего, он начнет операцию назначения до того, как Solo зарегистрирует свой ActivityMonitor. Solo.finishOPenedActivities() полагается на список, который он собрал из ActivityMonitor.

В соответствии с ответом @Guillaume я вызываю этот метод из тестового примера или из tearDown():

private void backOutToHome() {
    boolean more = true;
    while(more) {
        try {
            getInstrumentation().sendKeyDownUpSync(KeyEvent.KEYCODE_BACK);
        } catch (SecurityException e) { // Done, at Home.
            more = false;
        }
    }
}

Ответ 5

Если вы запустите свою сборку с помощью maven или ant (Robotium - это удобная оболочка для JUnit-Tests), есть возможность разблокировать новый процесс для каждого тестового класса или даже тестового примера. Это обеспечивает чистую среду, но замедляет выполнение теста.

Я лично предпочитаю придерживаться vanilla Junit/TestNG и использовать насмешку (с jMockit), чтобы обеспечить правильное взаимодействие с моим кодом и Android. См. Пример здесь:

https://github.com/ko5tik/andject/blob/master/src/test/java/de/pribluda/android/andject/ViewInjectionTest.java

Ответ 6

Вы можете попробовать удалить super.tearDown();

Ответ 7

Мое решение:

    @Override
    public void tearDown() throws Exception {

        solo.finishOpenedActivities();

        super.tearDown();
    }