Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Was Sie testen sollten, hängt von Faktoren wie dem Typ der Anwendung, dem Entwicklungsteam, der Menge an Legacy-Code und der verwendeten Architektur ab. In den folgenden Abschnitten wird beschrieben, was Anfänger bei der Planung von Tests in ihrer App berücksichtigen sollten.
Organisation von Testverzeichnissen
Ein typisches Projekt in Android Studio enthält zwei Verzeichnisse, die Tests abhängig von ihrer Ausführungsumgebung enthalten. Organisieren Sie Ihre Tests wie beschrieben in den folgenden Verzeichnissen:
Das Verzeichnis androidTest sollte die Tests enthalten, die auf echten oder virtuellen Geräten ausgeführt werden. Zu diesen Tests gehören Integrationstests, End-to-End-Tests und andere Tests, bei denen die JVM allein nicht die Funktionalität Ihrer Anwendung validieren kann.
Das Verzeichnis test sollte die Tests enthalten, die auf Ihrem lokalen Computer ausgeführt werden, z. B. Einheitentests. Im Gegensatz zum obigen können dies Tests sein, die auf einer lokalen JVM ausgeführt werden.
Wichtige Einheitentests
Wenn Sie die Best Practices befolgen, sollten Sie in den folgenden Fällen Einheitentests verwenden:
Unittests für ViewModels oder Presenters
Einheitentests für die Datenschicht, insbesondere Repositories. Der Großteil der Datenschicht sollte plattformunabhängig sein. So können Test-Doubles Datenbankmodule und Remote-Datenquellen in Tests ersetzen. Weitere Informationen finden Sie in der Anleitung zur Verwendung von Test-Doubles in Android.
Einheitentests für andere plattformunabhängige Ebenen wie die Domainebene, z. B. für Anwendungsfälle und Interaktionen.
Einheitentests für Dienstprogrammklassen wie Stringbearbeitung und Mathematik.
Grenzfälle testen
Einheitentests sollten sich sowohl auf normale als auch auf Grenzfälle konzentrieren. Grenzfälle sind ungewöhnliche Szenarien, die menschliche Tester und größere Tests wahrscheinlich nicht erkennen werden. Hier einige Beispiele:
Mathematische Operationen mit negativen Zahlen, Nullen und Grenzbedingungen
Alle möglichen Netzwerkverbindungsfehler.
Beschädigte Daten, z. B. fehlerhaftes JSON-Format.
Simulieren des vollen Speichers beim Speichern in einer Datei.
Objekt, das mitten in einem Prozess neu erstellt wird (z. B. eine Aktivität beim Drehen des Geräts).
Zu vermeidende Einheitentests
Einige Einheitentests sollten aufgrund ihres niedrigen Werts vermieden werden:
Tests, die die korrekte Funktionsweise des Frameworks oder einer Bibliothek prüfen, nicht des Codes.
Framework-Einstiegspunkte wie Aktivitäten, Fragmente oder Dienste sollten keine Geschäftslogik haben, sodass Einheitentests keine Priorität haben sollten. Einheitentests für Aktivitäten sind wenig wertvoll, da sie hauptsächlich Framework-Code abdecken und eine aufwendigere Einrichtung erforderlich ist. Instrumentierte Tests wie UI-Tests können diese Klassen abdecken.
UI-Tests
Es gibt verschiedene Arten von UI-Tests, die Sie verwenden sollten:
Mit Bildschirm-UI-Tests werden wichtige Nutzerinteraktionen auf einem einzigen Bildschirm geprüft. Sie führen Aktionen wie das Klicken auf Schaltflächen, die Eingabe von Formularen und die Überprüfung sichtbarer Status aus. Ein Testkurs pro Bildschirm ist ein guter Ausgangspunkt.
Nutzerfluss-Tests oder Navigationstests, die die gängigsten Pfade abdecken. Diese Tests simulieren, wie sich ein Nutzer durch einen Navigationsfluss bewegt. Es handelt sich um einfache Tests, die bei der Überprüfung auf Laufzeitabstürze bei der Initialisierung nützlich sind.
Andere Tests
Es gibt spezialisiertere Tests wie Screenshot-Tests, Leistungstests und Monkey-Tests. Sie können Tests auch nach Zweck kategorisieren, z. B. Regressionen, Zugänglichkeit und Kompatibilität.
Weitere Informationen
Um isolierte Tests durchzuführen, müssen Sie häufig die Abhängigkeiten der zu testenden Person durch fiktive oder simulierte Abhängigkeiten ersetzen, die allgemein als "Test-Doubles" bezeichnet werden. Lesen Sie mehr dazu unter Test-Doubles in Android verwenden.
Wie Sie Unit- und UI-Tests erstellen, erfahren Sie in den Testcodelabs.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],null,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
