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

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

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

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

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

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

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

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

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

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

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

Причинами проблемы являются:

  1. Для получения списка всех действий в стеке нет API Android.
  2. Обходной путь для (1) заключается в том, чтобы использовать ActivityMonitor для отслеживания каждого запускающегося Действия.
  3. 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; } } } 

Если вы запустите свою сборку с помощью 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

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