Robotium. В наборе тестов на каждый следующий тест влияет предыдущий тест - PullRequest
Новая
       14

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

12 голосов
/ 21 октября 2011

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

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

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

Ответы [ 7 ]

5 голосов
/ 19 июня 2012

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

3 голосов
/ 26 июля 2012

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

    Intent i = new Intent();
    i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    setActivityIntent(i);
    solo = new Solo(getInstrumentation(), getActivity());
1 голос
/ 07 февраля 2012

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

  1. Нет Android API для получения списка всех действий в стеке.
  2. Обходной путь для (1) состоит виспользуйте ActivityMonitor для отслеживания каждого запускаемого действия.

  3. Robotium использует обходной путь, но он устанавливает свой ActivityMonitor ПОСЛЕ того, как тестовый случай ActivityInstrumentationTestCase2 начинает свою деятельность, то есть: 

    Activity activity = getActivity();
Solo solo = new Solo(getInstrumentation(), activity);

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

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

private void backOutToHome() {
    boolean more = true;
    while(more) {
        try {
            getInstrumentation().sendKeyDownUpSync(KeyEvent.KEYCODE_BACK);
        } catch (SecurityException e) { // Done, at Home.
            more = false;
        }
    }
}
1 голос
/ 13 декабря 2011

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

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

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

0 голосов
/ 16 ноября 2017

Мое решение: 

    @Override
    public void tearDown() throws Exception {

        solo.finishOpenedActivities();

        super.tearDown();
    }
0 голосов
/ 07 января 2016

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

0 голосов
/ 12 декабря 2011

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

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

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

...