Programa ampliado · Actualización noviembre de 2026
Clase avanzada: fundamentos y aplicación real
Lee los conceptos, reproduce el ejemplo en un proyecto de prueba y después completa el laboratorio. Los fragmentos marcados como didácticos requieren adaptarse a las versiones y dependencias del proyecto.
Una pirámide de pruebas razonable
Empieza por pruebas unitarias rápidas para lógica determinista: validaciones, reglas de precio o cálculo de fechas. Prueba integración entre capas con dobles o bases de datos de prueba, y reserva pruebas instrumentadas de interfaz para flujos críticos que requieran dispositivo. No toda interacción merece una prueba end-to-end: suelen ser más lentas y frágiles. Anota qué riesgo cubre cada prueba antes de crearla.
fun sumar(precios: List<Int>): Int = precios.sum()
@Test fun totalVacioEsCero() {
assertEquals(0, sumar(emptyList()))
}
@Test fun sumaVarios() {
assertEquals(350, sumar(listOf(100, 250)))
}
Diseño para poder probar
Mantén cálculos libres de Android cuando sea posible y entrega dependencias mediante interfaces. Evita que un test dependa del orden de otros o de red pública. Para corrutinas y flujos, usa herramientas de pruebas de corrutinas y controla el avance del tiempo virtual. Las pruebas de base de datos deben preparar y limpiar datos propios sin alterar información real.
Estados de UI y accesibilidad
Prueba carga, contenido, vacío, error y reintento; verifica también orientación, modo oscuro, escalado del texto y navegación mediante lectores de pantalla cuando corresponda. En Compose, utiliza etiquetas semánticas estables en lugar de coordenadas de pantalla. Un botón visible pero no operable mediante teclado o servicios de accesibilidad sigue siendo un defecto.
Depurar fallos intermitentes
Cuando un test falla solo a veces, captura logs, entorno y semilla de datos; evita ocultarlo con sleep arbitrarios. Prefiere esperar condiciones observables. En CI ejecuta primero pruebas rápidas y después escenarios instrumentados en una matriz reducida pero representativa de versiones y tamaños de pantalla.
Laboratorio guiado con evidencia
Este laboratorio es un escenario propuesto, no una afirmación sobre el código o las métricas de las aplicaciones de AppInitDev. No utilices información personal ni credenciales reales durante la práctica.
Especificar y automatizar reglas de una app de notas
- Escribe pruebas para una validación pura con entrada vacía, normal y fuera de rango.
- Inyecta un repositorio simulado que devuelva éxito y fallo.
- Crea un caso instrumentado que compruebe mensaje de error y botón de reintento.
- Ejecuta los tests repetidamente para detectar dependencia del orden.
Entrega esperada: Conjunto de pruebas con resultados y un fallo corregido.
Comprueba lo que entendiste
¿Una prueba visual reemplaza la de lógica?
No. Cubren riesgos distintos y conviene combinarlas con criterio.
Autoevaluación: ¿Puedes explicar el objetivo, los datos de entrada y las condiciones de error sin copiar instrucciones? Si la respuesta es no, repite primero un caso mínimo. No confundas una herramienta que se ejecuta con una validación completa en producción.
Unidad ampliada · Subtemas y casos resueltos
Profundización temática: decisiones y criterios
Subtema 1. Pirámide de pruebas y contratos
Coloca las reglas de negocio puras en tests unitarios rápidos; usa pruebas de integración para bases de datos y pruebas UI cuando un flujo depende de accesibilidad, foco o navegación real. Define condiciones de entrada y salida y añade casos vacíos o erróneos. Una prueba que solo confirma que la pantalla existe aporta poco. Mide fallos reproducibles, no cantidad arbitraria de tests. [1]
Subtema 2. Caso concreto explicado
Escenario de práctica: Una regla de precio admite 0 unidades, rechaza negativas y conserva redondeo en moneda; la UI refleja el error sin cerrarse.
El primer paso es describir el comportamiento esperado sin depender de una pantalla concreta. Después hay que preparar entradas controladas y registrar resultados observados. Si el resultado difiere, conviene distinguir un error de la explicación, una limitación del entorno y un defecto de implementación. El objetivo no es completar una casilla por intuición: es producir evidencia que otra persona pueda repetir. [2]
Subtema 3. Protocolo de comprobación y rúbrica
- Prepara un caso válido basado en el ejemplo y describe los prerrequisitos que necesita.
- Prueba una entrada vacía, ausente o inválida y escribe cómo debería responder el sistema.
- Repite en un segundo contexto relevante (otra pantalla, otro idioma, sin conexión o distinta versión), si corresponde a esta unidad.
- Conserva una tabla con entrada, resultado esperado, resultado observado y conclusión.
- Contrasta al menos una decisión con la documentación oficial y registra la fecha de consulta.
Subtema 4. Notas técnicas y errores que conviene evitar
Para profundizar: La primera fuente describe el mecanismo principal; la segunda amplía las condiciones o métodos de comprobación. No son certificaciones del ejemplo inventado: consulta las secciones relevantes de cada documento.
Referencias y citas de esta unidad
- Android Developers. Pruebas de Jetpack Compose. Fuente primaria ↗. Consultada: 9 de noviembre de 2026.
- Android Developers. Guía de arquitectura de aplicaciones. Fuente primaria ↗. Consultada: 9 de noviembre de 2026.
Pregunta de reflexión: ¿qué evidencia demostraría que comprendiste este ejemplo?
Debes poder reproducir el caso, explicar el mecanismo, mostrar una prueba negativa y justificar una decisión con una fuente primaria. Si no es posible repetirlo, documenta qué información falta.
Registra tu progreso en este navegador
Esta sección almacena únicamente las casillas y tus notas mediante almacenamiento local del navegador. Puedes borrar los datos cuando quieras. No escribas contraseñas ni información confidencial.
Referencia primaria para ampliar
Consulta el alcance exacto de las APIs y políticas en su fuente oficial antes de aplicar un cambio en producción. Los ejemplos de esta página son educativos y no sustituyen una revisión de requisitos actuales.