Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Co należy przetestować, zależy od czynników takich jak typ aplikacji, zespół programistyczny, ilość starszego kodu i używana architektura. Sekcje poniżej zawierają informacje o tym, co początkujący powinien wziąć pod uwagę przy planowaniu, co warto przetestować w aplikacji.
Organizacja katalogów testowych
Typowy projekt w Android Studio zawiera 2 katalogi, w których przeprowadzane są testy – w zależności od środowiska wykonawczego. Uporządkuj testy w następujących katalogach zgodnie z opisem:
Katalog androidTest powinien zawierać testy wykonywane na rzeczywistych lub wirtualnych urządzeniach. Do takich testów zaliczają się testy integracji, testy kompleksowe i inne, w których tylko JVM nie może zweryfikować funkcji aplikacji.
Katalog test powinien zawierać testy wykonane na komputerze lokalnym, takie jak testy jednostkowe. W przeciwieństwie do powyższych testów są to testy wykonywane na lokalnej maszynie wirtualnej JVM.
Niezbędne testy jednostkowe
Zgodnie ze sprawdzonymi metodami korzystaj z testów jednostkowych w tych przypadkach:
Testy jednostkowe elementów ViewModels i prowadzących.
Testy jednostkowe warstwy danych, zwłaszcza repozytoriów. Większość warstwy danych powinna być niezależna od platformy. Dzięki temu podwójne preparaty testowe zastępujące
moduły bazy danych i zdalne źródła danych w testach. Zapoznaj się z przewodnikiem na temat używania podwójnej precyzji kodu na Androidzie.
Testy jednostkowe innych warstw niezależnych od platformy, takich jak warstwa Domena, pod kątem przypadków użycia i interaktywnych elementów.
Testy jednostkoweklas narzędzi, takich jak operacje manipulacyjne ciągami tekstowymi i działania matematyczne.
Testowanie brzegowych przypadków
Testy jednostkowe powinny skupiać się zarówno na przypadkach normalnych, jak i skrajnych. Skrajne przypadki to rzadkie sytuacje, których nie wykrywają testerzy ani większe testy. Przykłady:
Operacje matematyczne z wykorzystaniem liczb ujemnych, 0 i warunków granic
Wszystkie możliwe błędy połączenia sieciowego.
uszkodzone dane, np. nieprawidłowy format JSON;
Symulowanie pełnego miejsca na dane podczas zapisywania w pliku.
Obiekt odtwarzany w trakcie procesu (np. działanie przy rotacji urządzenia).
Testy jednostkowe, których należy unikać
Niektórych testów jednostkowych nie należy unikać ze względu na ich niską wartość:
Testy, które weryfikują prawidłowe działanie platformy lub biblioteki, a nie Twojego kodu.
Punkty wejścia platformy, takie jak działania, fragmenty lub usługi, nie powinny mieć logiki biznesowej, więc testowanie jednostkowe nie powinno być priorytetem. Testy jednostkowe działań mają niewielką wartość, ponieważ obejmowałyby głównie kod platformy i wymagały bardziej skomplikowanej konfiguracji. Obejmują one testy instrumentalne,
np. testy interfejsu.
Testy interfejsu
Istnieje kilka rodzajów testów interfejsu, które warto wykonać:
Testy interfejsu ekranu pozwalają sprawdzać kluczowe interakcje użytkowników na jednym ekranie. Realizują one działania, takie jak klikanie przycisków, pisanie w formularzach i sprawdzanie widocznych stanów. Dobrym punktem wyjścia jest jedna klasa testowa na każdy ekran.
Testy przepływu użytkowników lub Testy nawigacji, które obejmują najczęstsze ścieżki. Te testy symulują użytkownika poruszającego się przez proces nawigacji. Są to proste testy, przydatne do sprawdzania awarii w czasie działania podczas inicjowania.
Inne testy
Istnieją bardziej specjalistyczne testy, takie jak testy zrzutów ekranu, testy wydajności i małpy. Testy możesz też dzielić na kategorie według celu, np. regresji, ułatwień dostępu i zgodności.
Więcej materiałów
Aby przeprowadzić testy w izolacji, często trzeba zastąpić zależności testowanego podmiotu zależnościami fałszywymi lub pozornymi, czyli ogólnie nazywanymi „podwójnymi testami”. Przeczytaj o tym w artykule Używanie podwójnej precyzji na potrzeby testów na Androidzie.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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)."]]
