Pruebas unitarias de Android y por qué no debería hacerlo;) | Por Malcolm Maema | Marzo de 2022
Sí, es clickbait y la prueba es muy importante (^o^). Si tú, como yo, nunca has escrito pruebas para ninguno de mis proyectos personales, este artículo es para ti. Cubriremos los aspectos básicos de cómo escribir pruebas unitarias para aplicaciones de Android y por qué esto es importante para su crecimiento como desarrollador.
A menudo escucho a los desarrolladores reiterar que si el código que está escribiendo funciona, ¿por qué debería probarlo? ¡Funciona bien! ? Si bien esto es cierto, puede que no siempre sea así. A medida que la base de código crece y evoluciona, es posible que se rompa parte del código y es posible que deba corregirlo antes de continuar. Aquí es donde entran las pruebas unitarias. A medida que continúe construyendo sobre su base de código, notará ciertos cambios importantes. Ahora puede ver si tiene pruebas, entonces puede asegurarse de no haber roto su base de código porque algunas de esas pruebas pueden fallar. No es magia, si no ha escrito código, en algún momento escribirá código que romperá su base de código.
Puede escribir diferentes tipos de pruebas para su aplicación de Android. Éstos incluyen:
- prueba de unidad
- Pruebas de integración
- pruebas de extremo a extremo
- prueba de interfaz de usuario
- Pruebas de rendimiento
- prueba de funcionamiento
- prueba de humo
- Pruebas de regresión
- prueba de carga
Diferentes bibliotecas son adecuadas para diferentes tipos de pruebas. Algunas bibliotecas de prueba comunes incluyen/pero no se limitan a:
- mochito
- JUnit
- Café fuerte
- cargar vista
- robot electrico
- servidor web simulado
A los efectos de este artículo, utilizaremos JUnit como nuestro conjunto de pruebas. Ahora, si ha trabajado con MVVM anteriormente, conceptos como ViewModel y LiveData le resultarán familiares.En caso afirmativo, le recomiendo que lea este artículo/serie asociación
El concepto básico cuando se trata de vistas y modelos de vista es que tiene una vista y un modelo de vista. El ViewModel es responsable de manejar la lógica de la Vista. La Vista es responsable de mostrar los datos del ViewModel.
arquitectura tradicional como MVC Se utiliza un enfoque diferente para esto, ya que consta de tres componentes clave:
– Modelo: Datos que se muestran
– vista: interfaz de usuario para mostrar datos
– controlador: Lógica para manejar datos y UI
En este artículo, no entraremos en los detalles de cómo se compara con MVVM.
De vuelta a las pruebas. Si ViewModel es responsable de manejar la lógica de View, ¿cómo se puede probar? Android viene incluido con JUnit.
Supongamos que tenemos una aplicación PerfilActividad.kt con uno ProfileViewModel.kt En esta actividad podemos ver información básica sobre el usuario como nombre de usuario, dirección de correo electrónico, foto de la caraPodemos probarlo creando una clase de prueba y un método de prueba.Un simple truco que uso para generar clases de prueba en Android Studio es ingresar al archivo kotlin y presionar CTRL + MAYÚS + TEsto debería generar una clase de prueba para usted con métodos de prueba prediseñados.
Ahora deberíamos tener un ProfileViewModelTest.kt documento.Nuestro modelo de vista de perfil tiene un obtenerUsuario() Métodos que devuelven objetos de tipo LiveData Respuesta del usuario.
nuestro obtenerUsuario() has uno asincrónico Nuestro repositorio se llama utilizando una rutina de Kotlin, que se encarga de proporcionar una API limpia para acceder a los datos. Esto significa que el repositorio puede recopilar datos de diferentes fuentes de datos (diferentes REST API, cachés, almacenamiento de bases de datos locales) y hacer que estos datos estén disponibles para el resto de la aplicación.En nuestro caso, nuestro repositorio se encarga de servir datos desde el backend [backend]
porque esperamos un tipo de respuesta Respuesta del usuario cuando llamamos obtenerUsuario() Como puede ver en el código anterior, podemos probar esto burlándonos de la respuesta (Cuerda 46–52). Ahora a explicar lo que pasó en la prueba.
- Declaramos el repositorio como lateinit var. Esto significa que no podemos inicializar el contexto hasta que lo tengamos.
- Declaramos viewModel como lateinit var
Después de esto puedes ver una nota. @obtener:regla Esta es una regla JUnit que nos permite ejecutar pruebas en un proceso separado. Esto es útil para probar código asíncrono.
- declaramos excepción de instanciación y Reglas de rutinaEstos dos se utilizan para ejecutar pruebas en un contexto coroutine.
Puede leer más sobre las anotaciones JUnit [here]
Después de declarar la variable lateinit, ahora podemos inicializar el repositorio y viewModel. Inicializamos nuestro repositorio con mock. Ahora para nuestra prueba real.Tú lo notarás @prueba anotaciónEsta es una anotación JUnit que le dice a JUnit que este es un método de prueba.en nuestro obtenerUsuario() nuestra manera
Crear Probar la respuesta del usuario objeto y establecer datos de muestra para él.Entonces llamamos obtenerUsuario() método y afirmar que la respuesta es igual a Probar la respuesta del usuario.
¿Cómo ayuda esto?Esto significa que si nuestro Respuesta del usuario Con los objetos modificados en el backend, podemos probar nuestra aplicación para asegurarnos de que aún funcione como se esperaba. ¡Es genial! ?
Espero que este artículo lo haya convencido para escribir más pruebas y por qué son importantes en el ciclo de desarrollo de su aplicación.Para ver más pruebas y cómo hacerlas, puede consultar nuestro repositorio de github [here]
Me encantaría escuchar sus opiniones y comentarios, especialmente si es nuevo en escribir pruebas en Android.
- Arquitectura MVVM, ViewModel y LiveData (asociación)
- Comience a escribir casos de prueba funcionales en Android (asociación)
- Prueba de humo simple de Kotlin (Retrofit, JUnit y producción sin errores) (asociación)
- Pruebas de regresión en el desarrollo móvil (asociación)
- Pruebe los conceptos básicos de las aplicaciones de Android (asociación)
- Tutorial JUnit 5 – Aprende a escribir pruebas unitarias (asociación)
- Pruebe su ViewModel de Android – con ejemplo (asociación)
- Pruebas unitarias para ViewModels (asociación)
