Pirámide de testing en Android

Si no sabes por dónde empezar con el testing en Android, la pirámide de testing te da una guía práctica para distribuir el esfuerzo entre pruebas unitarias, de integración y end-to-end sin gastar tiempo en lo que no aporta valor. Es una herramienta visual pensada para developers que quieren confianza en su código sin perseguir métricas vacías.

¿Qué es la pirámide de testing y por qué importa?

La pirámide de testing es un modelo que muestra cómo balancear los distintos tipos de pruebas según su costo y velocidad. La idea es simple: no todos los tests cuestan lo mismo ni cubren los mismos riesgos, así que conviene hacer muchos de los baratos y pocos de los caros.

La distribución recomendada que verás en la clase es clara:

• 70% tests unitarios en la base.
• 20% tests de integración en el centro.
• 10% tests end-to-end en la cima.

Cuanto más subes en la pirámide, más lento y costoso se vuelve testear. Por eso el equilibrio es la clave [0:30].

¿Por qué no hacer 100% de tests end-to-end? Porque son lentos, pesados y frágiles. Mantenerlos como única estrategia te haría perder velocidad de desarrollo sin aportar más confianza real.

¿Cómo funcionan los tests unitarios en Android?

Los tests unitarios son la base de la pirámide. Son rápidos, confiables y fáciles de mantener porque prueban una sola clase o función, como una suma de 2 + 3 que debe devolver 5 [1:05].

Corren directamente sobre la Java Virtual Machine, sin necesidad de Android, lo que significa milisegundos de ejecución y bajo consumo de recursos. No requieren emulador ni dispositivo físico.

¿Para qué sirven exactamente?

Son ideales cuando quieres validar:

• Lógica pura.
• Cálculos y validaciones.
• Utilidades y helpers.
• Reglas de negocio.

Esta es tu primera línea de defensa contra bugs lógicos. Si algo se puede probar acá, pruébalo acá.

¿Qué cubren los tests de integración?

Los tests de integración verifican cómo dos o más componentes trabajan juntos. Un ejemplo típico es un DAO con Room guardando datos junto con un repositorio que los expone [1:35].

A diferencia de los unitarios, estos usan dependencias reales: bases de datos en memoria, Retrofit, o cualquier pieza que conecte tu código con el mundo. Eso los vuelve más poderosos pero también más frágiles si no aíslas bien el entorno.

La recomendación no es cubrir todo con integración, sino apuntar a los puntos clave donde hay interacción real entre capas. Ahí es donde aparecen los bugs que un test unitario nunca vería.

¿Cuándo escribir un test de integración? Cuando dos componentes reales se comunican y un fallo entre ellos rompería una funcionalidad importante, como persistencia o llamadas a red.

¿Qué son los tests end-to-end y cuándo usarlos?

Los tests end-to-end son los que más se parecen a lo que hace un usuario real. Simulan taps, scrolls, escritura y navegación dentro de la app, como si alguien la estuviera usando [2:05].

Se ejecutan en un emulador o dispositivo físico, así que son lentos y pesados, pero necesarios para validar flujos completos. Un ejemplo concreto: abrir la app, crear una tarea, guardarla y verificar que aparece en la lista [2:25].

La regla aquí es clara: no hagas muchos, solo los esenciales, esos flujos que no pueden fallar nunca.

¿Cómo balancear costo y beneficio entre tipos de tests?

Cada tipo de test tiene una relación distinta entre realismo y velocidad. Cuanto más realista es la prueba, más lenta resulta. Cuanto más rápida, menos contexto simula. Por eso la pirámide propone muchos unitarios, algunos de integración y pocos end-to-end.

Cada nivel cubre un riesgo diferente:

• Los unitarios evitan bugs lógicos.
• Los de integración detectan fallos entre componentes.
• Los end-to-end validan la experiencia final del usuario.

No pongas los tipos de test a competir, haz que trabajen juntos.

¿Debes buscar el 100% de cobertura?

No. Perseguir el 100% de cobertura suele ser una métrica vacía. Tu enfoque debería estar en la lógica de negocio y en los flujos más usados de tu app.

Pregúntate cosas concretas: ¿qué pasa si falla la creación de un usuario? ¿Y si no se guarda una tarea? Esas son las preguntas que deberían guiar tu estrategia, no un porcentaje en un dashboard.

A veces, probar todo no te hace mejor developer, te hace más lento. Combina tests automáticos con validaciones manuales bien pensadas. Tu meta no es testear todo, es tener confianza de que lo importante no se rompe.

Con esta base clara, ya puedes empezar a escribir tests reales y adaptados a cada capa de tu app, comenzando desde la lógica pura en clases pequeñas y subiendo poco a poco. ¿Cómo distribuyes hoy tu esfuerzo de testing? Cuéntalo en los comentarios.