Saltar al contenido principal

Probar apps de Flutter

Aprende más sobre los diferentes tipos de pruebas y cómo escribirlas.

Cuantas más funciones tenga tu app, más difícil será probarla manualmente. Las pruebas automatizadas ayudan a garantizar que tu app funcione correctamente antes de publicarla, manteniendo al mismo tiempo la velocidad de entrega de funciones y correcciones de errores.

Las pruebas automatizadas se dividen en varias categorías:

En general, una app bien probada tiene muchas pruebas unitarias y de widgets, rastreadas por cobertura de código (code coverage), además de suficientes pruebas de integración para cubrir todos los casos de uso importantes. Este consejo se basa en el hecho de que existen compromisos entre los diferentes tipos de pruebas, que se muestran a continuación.

Compromiso (Tradeoff)Unitaria (Unit)WidgetIntegración
ConfidenceBajoMás altoEl más alto
Maintenance costBajoMás altoEl más alto
DependenciesPocasMásLa mayoría
Execution speedRápidoRápidoLento

Pruebas unitarias

#

Una prueba unitaria prueba una sola función, método o clase. El objetivo de una prueba unitaria es verificar la corrección de una unidad de lógica bajo una variedad de condiciones. Las dependencias externas de la unidad bajo prueba generalmente se simulan (mocked out). Las pruebas unitarias generalmente no leen ni escriben en el disco, no renderizan en pantalla ni reciben acciones del usuario desde fuera del proceso que ejecuta la prueba. Para obtener más información sobre pruebas unitarias, puedes ver las siguientes recetas o ejecutar flutter test --help en tu terminal.

Recetas

#

Pruebas de widgets

#

A prueba de widget (en otros frameworks de UI denominada prueba de componente) prueba un solo Widget. El objetivo de una prueba de widget es verificar que la UI del Widget se vea e interactúe según lo esperado. Probar un Widget implica múltiples clases y requiere un entorno de prueba que proporcione el contexto de ciclo de vida del Widget adecuado.

Por ejemplo, el Widget que se está probando debería ser capaz de recibir y responder a acciones y eventos del usuario, realizar el layout e instanciar Widgets hijos. Por lo tanto, una prueba de widget es más exhaustiva que una prueba unitaria. Sin embargo, al igual que una prueba unitaria, el entorno de una prueba de widget se reemplaza con una implementación mucho más simple que un sistema de UI completo.

Recetas

#

Pruebas de integración

#

Una prueba de integración prueba una app completa o una gran parte de una app. El objetivo de una prueba de integración es verificar que todos los widgets y servicios que se están probando funcionen juntos como se espera. Además, puedes usar pruebas de integración para verificar el rendimiento de tu app.

Generalmente, una prueba de integración se ejecuta en un dispositivo real o en un emulador del SO, como el Simulador de iOS o el Emulador de Android. La app bajo prueba normalmente se aísla del código del ejecutor de pruebas (test driver) para evitar sesgar los resultados.

El SDK de Flutter incluye el paquete integration_test. Sin embargo, este paquete no puede interactuar con la UI de la plataforma nativa, como cuadros de diálogo de permisos, notificaciones o vistas de plataforma. Para apps que necesitan interacciones nativas, puedes usar el paquete patrol, un framework de código abierto que extiende las capacidades de prueba de Flutter con soporte para plataformas nativas.

Para obtener más información sobre cómo escribir pruebas de integración, consulta la página de pruebas de integración.

Recetas

#

Servicios de integración continua

#

Los servicios de integración continua (CI) te permiten ejecutar tus pruebas automáticamente al enviar nuevos cambios de código. Esto proporciona comentarios oportunos sobre si los cambios de código funcionan según lo esperado y no introducen errores.

Para obtener información sobre la ejecución de pruebas en varios servicios de integración continua, consulta lo siguiente: