En primer lugar, las aplicaciones pequeñas creadas desde cero generalmente se prueban manualmente usando un emulador virtual en sistemas de gama alta o usando un teléfono Android externo para sistemas de gama baja, ya que el emulador puede causar retrasos o bloqueos del sistema en dispositivos de gama baja. .
Cuantas más funciones haya en la aplicación que creó, más difícil será probar la aplicación manualmente. Por lo tanto, realizar pruebas automatizadas garantiza que la aplicación funcione correctamente antes de publicarla.
Ahora, las pruebas automatizadas se pueden clasificar en algunas categorías:
- Una prueba de unidad
- Una prueba de integración
- Una prueba de widgets
Con base en los hechos, se recomienda que existan compensaciones entre los diferentes tipos de pruebas que mostraré en la siguiente tabla:
| Unidad | Widget | Integración | |
|---|---|---|---|
| Confianza | Bajo | Más alto | más alto |
| Costo de mantenimiento | Bajo | Más alto | más alto |
| dependencias | Pocos | Más | La mayoría |
| Velocidad de ejecución | Rápido | Rápido | Lento |
Veamos una breve explicación de los diferentes tipos de pruebas:
Prueba de unidad :
Una prueba unitaria, como sugiere el nombre, prueba métodos, funciones o incluso clases individuales. El único objetivo de la prueba unitaria es verificar la exactitud de una unidad de lógica bajo varias condiciones. La prueba unitaria generalmente no escribe en el disco, ni lee del disco, ni lee las instrucciones del usuario desde fuera del proceso que ejecuta la prueba. Las dependencias externas de la unidad bajo prueba generalmente se burlan.
Examen de integración :
La prueba de integración realiza una prueba en la sección más grande de la aplicación o incluso prueba la aplicación completa según el requisito. El objetivo principal de esta prueba es verificar si todos los widgets o servicios que se prueban funcionan juntos perfectamente como se esperaba o no. Además, el rendimiento de la aplicación también se puede probar con esta aplicación.
La aplicación bajo prueba generalmente se aísla del código del controlador de prueba para evitar sesgar los resultados. Esta prueba generalmente se ejecuta en un dispositivo real o en emuladores virtuales, como un simulador de Android o un simulador de iOS.
Servicios de integración continua:
Los servicios de integración continua le permiten ejecutar pruebas automáticamente cada vez que se detecta un cambio en el código. Esto proporciona comentarios oportunos sobre si los cambios en el código funcionan como se esperaba y no presenta ningún error.
Prueba de widget:
En algunos casos, la prueba del widget también se denomina prueba de componentes. El objetivo de esta prueba es variar la apariencia y el diseño de la interfaz de usuario y la interacción con el usuario según lo esperado. La prueba de widgets implica probar múltiples clases.
Por ejemplo, el widget que se está probando debe poder interactuar con los usuarios y responder a los comandos del usuario, realizar diseños e iniciar el funcionamiento de los widgets secundarios. Por lo tanto, una prueba de widget es más completa 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 que es mucho más fácil y simple que un sistema de interfaz de usuario completo.
Publicación traducida automáticamente
Artículo escrito por aarjesh500 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA