Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Lo que debes probar depende de factores como el tipo de app, el equipo de desarrollo, la cantidad de código heredado y la arquitectura usada. En las siguientes secciones, se describe lo que un principiante podría considerar cuando planifica qué probar en su app.
Organización de directorios de prueba
Un proyecto típico de Android Studio contiene dos directorios que contienen pruebas según su entorno de ejecución. Organiza las pruebas en los siguientes directorios como se describe:
El directorio androidTest debe contener las pruebas que se ejecutan en dispositivos reales o virtuales. Estas pruebas incluyen pruebas de integración, de extremo a extremo y otras en las que la JVM por sí sola no puede validar la funcionalidad de tu app.
El directorio test debe contener las pruebas que se ejecutan en tu máquina local, como las pruebas de unidades. A diferencia de lo anterior, estas pueden ser pruebas que se ejecutan en una JVM local.
Pruebas de unidades esenciales
Cuando sigas las prácticas recomendadas, debes asegurarte de usar pruebas de unidades en los siguientes casos:
Pruebas de unidades para ViewModels o presentadores.
Pruebas de unidades para la capa de datos, especialmente los repositorios La mayor parte de la capa de datos debe ser independiente de la plataforma. Esto permite que los dobles de prueba reemplacen los módulos de bases de datos y las fuentes de datos remotas en las pruebas. Consulta la guía sobre cómo usar pruebas dobles en Android.
Pruebas de unidades para otras capas independientes de la plataforma, como la capa Dominio, como sucede con los casos de uso y las interacciones.
Pruebas de unidades para clases de utilidad, como manipulación de strings y matemáticas
Prueba de casos extremos
Las pruebas de unidades deben enfocarse tanto en casos normales como en extremos. Los casos extremos son situaciones poco comunes
que los verificadores manuales y las pruebas más grandes no pueden detectar. Los siguientes son algunos ejemplos:
Simula el almacenamiento completo cuando se guarda en un archivo.
El objeto que se recrea en medio de un proceso (como una actividad cuando se rota el dispositivo).
Pruebas de unidades que se deben evitar
Algunas pruebas de unidades deben evitarse debido a su bajo valor:
Pruebas que verifican el funcionamiento correcto del framework o una biblioteca, no tu código.
Los puntos de entrada del framework, como actividades, fragmentos o servicios, no deben tener lógica empresarial, por lo que las pruebas de unidades no deben ser una prioridad. Las pruebas de unidades para actividades tienen poco valor, ya que abarcarían principalmente el código del framework y requieren una configuración más compleja. Las pruebas de instrumentación, como las pruebas de IU, pueden abarcar estas clases.
Pruebas de la IU
Hay varios tipos de pruebas de IU que debes emplear:
Las pruebas de IU de pantalla verifican las interacciones críticas del usuario en una sola pantalla. Realizan acciones como hacer clic en botones, escribir formularios y verificar los estados visibles. Una clase de prueba por pantalla es un buen punto de partida.
Pruebas de flujo de usuarios o pruebas de Navigation, que abarcan las rutas de acceso más comunes. Estas pruebas simulan cómo un usuario se mueve por un flujo de navegación. Son pruebas simples y útiles para verificar si hay fallas en el tiempo de ejecución durante la inicialización.
Otras pruebas
Hay pruebas más especializadas, como pruebas de captura de pantalla, pruebas de rendimiento y pruebas monkey. También puedes categorizar las pruebas por propósito, como las regresiones, la accesibilidad y la compatibilidad.
Lecturas adicionales
Para realizar pruebas aisladas, a menudo, debes reemplazar las dependencias del sujeto de prueba por dependencias falsas o simuladas, llamadas "dobles de prueba" en general. Continúa leyendo sobre ellos en Cómo usar dobles de prueba en Android.
Si quieres aprender a crear pruebas de IU y unidades, consulta los codelabs de prueba.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)."]]
