Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce que vous devez tester dépend de facteurs tels que le type d'application, l'équipe de développement, la quantité d'ancien code et l'architecture utilisée. Les sections suivantes décrivent ce qu'un débutant peut prendre en compte lors de la planification des éléments à tester dans son application.
Organisation des répertoires de test
Un projet type dans Android Studio contient deux répertoires qui contiennent les tests en fonction de leur environnement d'exécution. Organisez vos tests dans les répertoires suivants, comme décrit ci-dessous:
Le répertoire androidTest doit contenir les tests exécutés sur des appareils réels ou virtuels. Ces tests incluent les tests d'intégration, les tests de bout en bout et d'autres tests dans lesquels la JVM seule ne peut pas valider le fonctionnement de votre application.
Le répertoire test doit contenir les tests qui s'exécutent sur votre ordinateur local, tels que les tests unitaires. Contrairement à ce qui précède, il peut s'agir de tests exécutés sur une JVM locale.
Tests unitaires essentiels
En suivant les bonnes pratiques, veillez à utiliser les tests unitaires dans les cas suivants:
Les tests unitaires pour les ViewModels ou les présentateurs.
Tests unitaires pour la couche de données, en particulier pour les dépôts. La majeure partie de la couche de données
doit être indépendante de la plate-forme. Cela permet aux doubles de test de remplacer les modules de base de données et les sources de données distantes lors des tests. Consultez le guide sur l'utilisation des doubles de test sous Android.
Les tests unitaires pour d'autres couches indépendantes de la plate-forme, telles que la couche Domaine, comme avec les cas d'utilisation et les interactions.
Tests unitaires pour les classes utilitaires telles que la manipulation de chaînes et les calculs mathématiques.
Tester les cas limites
Les tests unitaires doivent se concentrer à la fois sur les cas normaux et extrêmes. Les cas limites sont des scénarios peu courants que les testeurs humains et les tests plus importants sont peu susceptibles de détecter. Voici quelques exemples:
Opérations mathématiques utilisant des nombres négatifs, des zéros et des conditions limites.
Toutes les erreurs de connexion réseau possibles.
Données corrompues (format JSON, par exemple)
Simuler le stockage complet lors de l'enregistrement dans un fichier
Objet recréé au milieu d'un processus (par exemple, une activité lors de la rotation de l'appareil).
Tests unitaires à éviter
Certains tests unitaires doivent être évités en raison de leur faible valeur:
Des tests qui vérifient le bon fonctionnement du framework ou d'une bibliothèque, et non de votre code.
Les points d'entrée du framework tels que les activités, les fragments ou les services ne doivent pas avoir de logique métier. Par conséquent, les tests unitaires ne doivent pas être une priorité. Les tests unitaires pour les activités n'ont que peu d'intérêt, car ils couvrent principalement le code du framework et nécessitent une configuration plus complexe. Les tests d'instrumentation tels que les tests d'interface utilisateur peuvent couvrir ces classes.
Tests de l'interface utilisateur
Vous devez effectuer plusieurs types de tests d'interface utilisateur:
Les tests de l'UI de l'écran vérifient les interactions utilisateur critiques sur un seul écran. Elles effectuent des actions telles que cliquer sur des boutons, saisir des formulaires et vérifier les états visibles. Une classe de test par écran est un bon point de départ.
Tests de parcours utilisateur ou tests de navigation, couvrant les chemins les plus courants. Ces tests simulent le déplacement d'un utilisateur dans un flux de navigation. Ce sont des tests simples, utiles pour vérifier les plantages au moment de l'exécution lors de l'initialisation.
Autres tests
Il existe des tests plus spécialisés, tels que des tests de capture d'écran, des tests de performance et des tests du singe. Vous pouvez également classer les tests par objectif, comme les régressions, l'accessibilité et la compatibilité.
Complément d'informations
Pour effectuer des tests isolés, vous devez souvent remplacer les dépendances du sujet testé par de fausses ou fictives, appelées "doubles de test" en général. Pour en savoir plus, consultez Utiliser les doubles de test sur Android.
Si vous souhaitez apprendre à créer des tests unitaires et des tests d'interface utilisateur, consultez les ateliers de programmation de test.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
