Android Studio: Ich kann nicht in gemeinsame Einstellungen in instrumentiertem Test schreiben

Question

Ich versuche, einen Testfall zu schreiben, um eine Klasse zu überprüfen, die in gemeinsame Einstellungen schreibt. Ich benutze Android Studio v1.5.

In der guten alten Eklipse wurde bei Verwendung von AndroidTestCase eine zweite APK-Datei auf dem Gerät bereitgestellt, und Tests konnten mit dem Instrumentierungskontext ausgeführt werden, sodass Sie Tests unter Verwendung der gemeinsamen Einstellungen der Instrumentierungs-APK ausführen konnten, ohne die Haupt-APKs zu ändern vorhandene gemeinsame Voreinstellungsdateien.

Ich habe den ganzen Morgen damit verbracht herauszufinden, wie man in Android Studio-Tests einen Nicht-Null-Kontext bekommt. Anscheinend sind Komponententests für Eclipse nicht mit dem Test-Framework von Android Studio kompatibel, da der Aufruf getContext() null zurückgibt. Ich dachte, ich die Antwort in dieser Frage gefunden habe: Get context of test project in Android junit test case

Dinge im Laufe der Zeit verändert haben als alte Versionen von Android Studio nicht die volle Unterstützung beim Test hatte. Viele Antworten sind also nur Hacks. Offenbar jetzt statt InstrumentationTestCase oder AndroidTestCase erstrecken sollten Sie Ihre Tests wie folgt schreiben:

@RunWith(AndroidJUnit4.class) 
public class MyTest { 

    @Test 
    public void testFoo(){ 
     Context instrumentationContext = InstrumentationRegistry.getContext(); 
     Context mainProjectContext = InstrumentationRegistry.getTargetContext();    
    } 
} 

So jetzt habe ich eine nicht null Instrumentierung Kontext haben, und die getSharedPreferences Methode gibt eine Instanz, die aber eigentlich keine Einstellungsdatei zu funktionieren scheint wird geschrieben.

Wenn ich tun:

context = InstrumentationRegistry.getContext();  

Dann wird der SharedPreferences Editor schreibt und schreibt korrekt und keine Ausnahme ausgelöst. Ich kann bei näherer Betrachtung sehen, dass der Editor in diese Datei zu schreiben versucht:

data/data/<package>.test/shared_prefs/PREFS_FILE_NAME.xml 

Aber die Datei wird nie erzeugt noch geschrieben.

jedoch dies mit:

context = InstrumentationRegistry.getTargetContext(); 

der Editor korrekt funktioniert und die Präferenzen in diese Datei geschrieben werden:

/data/data/<package>/shared_prefs/PREFS_FILE_NAME.xml 

Die Einstellungen werden in privaten Modus instanziiert:

SharedPreferences sharedPreferences = context.getSharedPreferences(fileName, Context.MODE_PRIVATE); 

Soweit ich weiß, wurde nach dem Test keine Test-APK auf das Gerät hochgeladen. Dies könnte erklären, warum die Datei nicht mit dem Instrumentierungskontext geschrieben wurde. Ist es möglich, dass dieser Kontext ein gefälschter Kontext ist, der stillschweigend versagt?

Und wenn das der Fall wäre, wie könnte ich einen REAL Instrumentierungskontext erhalten, so dass ich Präferenzen schreiben kann, ohne die Hauptprojekteinstellungen zu ändern?

Answer 1

Es stellt sich heraus, dass Sie nicht über den Instrumentierungskontext in freigegebene Einstellungen schreiben können, und dies galt sogar in Eclipse. Dies wäre der äquivalente Test für die Eklipse:

Ich habe es gerade ausgeführt und es schlägt auch fehl. Die Einstellungen werden nie geschrieben. Ich denke, der Zugriff auf interne Speicherdateien ist in diesem Kontext verboten, da der Aufruf Context.getFilesDir() eine InvocationTargetException auslöst, und auch File.exists() über die Einstellungsdatei aufruft (Sie können überprüfen, mit welcher Datei der Editor den Debugger beschreibt, suchen Sie einfach nach einer privaten Variablen namens mFile innerhalb der this.$0 Mitgliedsinstanz).

Also lag ich falsch, dass dies tatsächlich möglich war. Ich habe zwar den Instrumentierungskontext für Datenzugriffsschichttests in der Vergangenheit verwendet, aber wir haben tatsächlich den Hauptkontext (AndroidTestCase.getContext()) verwendet, obwohl wir für die Präferenzen und SQLite-Dateien unterschiedliche Namen verwendet haben. Aus diesem Grund haben die Komponententests die regulären App-Dateien nicht geändert.

Answer 2

Hinweis: Sie können Android Studio weiterhin verwenden, um ältere Tests auszuführen, die InstrumentationTestCase, AndroidTestCase oder ActivityInstrumentationTestCase2 in Android Studio erweitern.

Die neue Testing Support Library bietet ActivityTestRule, um Funktionstests für eine einzelne Aktivität bereitzustellen.Ich glaube, Sie müssen eines dieser Objekte erstellen, bevor Sie versuchen, die für den Test verwendeten Instrumentation und/oder Context zu erhalten. The documentation for Espresso hat ein Beispiel für die Verwendung dieser Klasse.

Answer 3

Wenn Sie Klassen testen möchten, ohne eine Aktivität erstellen zu müssen, ist es am einfachsten, Robolectric zu verwenden. Robolectric bietet Ihnen einen Mock-Kontext, der alles tut, was ein Kontext tut. In der Tat ist dieser Kontext der Hauptgrund, warum ich Robolectric für Komponententests verwende.

Answer 4

Die Instrumentierung wird zusammen mit Ihrer Anwendung installiert. Die Anwendung läuft selbst und liest und schreibt somit ihre eigenen SharedPreferences.

Es ist seltsam, dass die SharedPreferences der Instrumentation gelöscht (oder nie erstellt), aber selbst wenn sie erstellt würden, würden Sie es schwer haben, sie in Ihre Anwendung im Test zu übergeben. Wie oben erwähnt, wird nur context.getSharedPreferences(); innerhalb Ihrer App aufrufen, wird immer noch die tatsächlichen apps Einstellungen, nie diejenigen Ihrer Instrumentierung.

Sie müssen eine Möglichkeit finden, die Einstellungen für Ihre zu testende Anwendung bereitzustellen. Eine gute Lösung für dieses Problem wäre es, die Einstellungen zu halten in Ihrem Application wie folgt aus:

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

    // add public getter/setter 
} 

Auf diese Weise können Sie

1. Solange Sie einen Kontext die Präferenzen aus einer Hand bekommen haben mit ((App) context.getApplicationContext()).getPreferences()
2. Legen Sie die Einstellungen selbst vor Ihre Tests und starten Sie alle Aktivitäten, um Ihre Testdaten zu injizieren.

In Ihrem Test-Setup dann die alle Einstellungen folgende rufen Sie

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

Achten Sie darauf, injizieren müssen Aktivitäten nach jedem Test richtig zu beenden, so dass jeder Test ihre eigenen Abhängigkeiten erhalten können.

Auch sollten Sie stark darüber nachdenken, nur die SharedPreferences Mockito, andere Frameworks zu verspotten, oder einfach die SharedPreferences Schnittstelle selbst implementieren, da dies die Überprüfung von Interaktionen mit Modellen erheblich vereinfacht.