Android Studio: нельзя записывать в общие настройки в инструментальном тесте

Ответ 1

Оказывается, вы не можете писать в общие настройки, используя контекст инструментария, и это было верно даже в eclipse. Это было бы эквивалентным тестом для eclipse:

import android.content.Context;
import android.content.SharedPreferences;
import android.test.InstrumentationTestCase;

public class SharedPrefsTest extends InstrumentationTestCase {

    public void test() throws Exception { 
        Context context = getInstrumentation().getContext();
        String fileName = "FILE_NAME";

        SharedPreferences sharedPreferences = context.getSharedPreferences(fileName, Context.MODE_PRIVATE);
        SharedPreferences.Editor editor = sharedPreferences.edit();
        editor.putString("key", "value");
        editor.commit();

        SharedPreferences sharedPreferences2 = context.getSharedPreferences(fileName, Context.MODE_PRIVATE);
        assertEquals("value", sharedPreferences2.getString("key", null));
    }
}

Я просто запускал его, и он тоже терпел неудачу. Настройки никогда не записываются. Я думаю, что доступ к внутреннему файлу хранилища запрещен в этом контексте, так как вызов Context.getFilesDir() вызывает InvocationTargetException и вызывает вызов File.exists() по файлу настроек (вы можете проверить, какой файл является редактором, записывающим на использование отладчика, просто найдите приватная переменная, называемая mFile внутри экземпляра члена this.$0).

Поэтому я ошибался, думая, что это действительно возможно. Хотя я использовал контекст инструментария для тестирования уровня доступа к данным в прошлом, но мы фактически использовали основной контекст (AndroidTestCase.getContext()), хотя мы использовали разные имена для предпочтений и файлов SQLite. И поэтому модульные тесты не изменяли обычные файлы приложений.

Ответ 2

Инструментарий будет установлен вместе с вашим приложением. Приложение будет работать само по себе, таким образом, считывая и записывая собственный SharedPreferences.

Нечетно, что SharedPreferences из Instrumentation удаляется (или никогда не создается), но даже если они будут созданы, вам будет сложно переносить их в тестируемое приложение. Как указано выше, просто вызов context.getSharedPreferences(); внутри вашего приложения будет по-прежнему предоставлять фактические настройки приложений, а не те, которые вам нужны.

Вам нужно будет найти способ предоставления предпочтений вашему приложению под тестированием. Хорошим решением для этого было бы сохранить предпочтения в вашем Application следующим образом:

public class App extends Application {
    SharedPreferences mPreferences;
    public void onCreate() {
        mPreferences = getSharedPreferences(fileName, Context.MODE_PRIVATE);
    }

    // add public getter / setter
}

Таким образом, вы можете

• Пока у вас есть контекст, вы получаете предпочтения из одного источника, используя ((App) context.getApplicationContext()).getPreferences()
• Задайте настройки самостоятельно перед запуском тестов и начните любые действия для ввода тестовых данных.

В вашей тестовой настройке затем вызовите следующее, чтобы ввести любые требуемые настройки

@Before
public void before() {
    ((App) InstrumentationRegistry.getTargetContext()).setPreferences(testPreferences);
}

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

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

Ответ 3

Обратите внимание, что вы все равно можете использовать Android Studio для запуска тестов старого стиля, которые расширяют InstrumentationTestCase, AndroidTestCase или ActivityInstrumentationTestCase2 в Android Studio.

Новая библиотека поддержки тестирования предоставляет ActivityTestRule, чтобы обеспечить функциональное тестирование одного действия. Я считаю, что вам нужно создать один из этих объектов, прежде чем пытаться получить Instrumentation и/или Context, используемые для теста. В документации для Espresso приведен пример использования этого класса.

Ответ 4

Если вы хотите тестировать классы без необходимости создания Activity, я нашел проще всего использовать Robolectric. Robolectric предоставляет вам фиктивный контекст, который делает все, что делает контекст. Фактически, этот контекст является основной причиной использования Robolectric для модульного тестирования.