Probando la capa API en Android – Probando los conceptos básicos | de Saurabh Pantalones | agosto 2022

alfa alfa! Copias

Casi todas las aplicaciones funcionan con API remotas para obtener, cargar y procesar datos. La biblioteca más utilizada para esta tarea es Retrofit. Como esto se ha convertido en una parte muy obvia del desarrollo de aplicaciones, se vuelve aún más importante probar nuestra capa API para validar nuestra configuración. En este artículo, exploraremos cómo escribir casos de prueba de unidad para nuestra capa de red y mejorarlos y evitar errores. Usaremos Retrofit como el resto del cliente. Entonces empecemos. El primer paso es agregar dependencias de actualización junto con gson en nuestro build.gradle como este // Implementación de actualización ‘com.squareup.retrofit2:retrofit:2.9.0’implementation ‘com.squareup.retrofit2:converter-gson: 2.9.0 ‘// Gsonimplementation ‘com.google.code.gson:gson:2.9.0’ Ahora definimos una interfaz donde enumeramos nuestras llamadas de punto final API de la siguiente manera. Asumimos aquí que vamos a recuperar algunos usuarios de la lista y un solo usuario por su ID. Luego definimos una interfaz de repositorio de usuarios para crear nuestra capa de datos de usuario de la siguiente manera. Ahora definimos su implementación de la siguiente manera, accesible a través del repositorio de usuarios. ¡En orden! Ahora hemos terminado de configurar nuestra capa. Continuemos con la configuración de prueba. Lo primero a tener en cuenta es que los casos de prueba están en prueba carpeta y no en Prueba de Android carpeta. No tenemos dependencias relacionadas con Android en esta capa. Agreguemos algunas dependencias y comprendamos por qué las necesitamos.

• prueba de corrutina: Nos ayuda a probar las corrutinas. Obtenemos áreas de prueba y despachadores para ejecutar rutinas.

// Coroutine testtestImplementation «org.jetbrains.kotlinx:kotlinx-coroutines-test:1.5.2»

• JUnit4: Nos proporciona API de marco de prueba unitaria para ejecutar pruebas localmente en JVM.

pruebaImplementación ‘junit:junit:4.13.2’

• Servidor web simulado: proporciona soporte para burlarse del servidor, lo que nos permite realizar llamadas a la API y obtener el resultado.

// implementación del servidor web simulado ‘com.squareup.okhttp3:servidorwebsimulado:4.10.0’

• verdad: Proporciona soporte para una mejor aserción y registro de resultados.

// Google Truth for AssertiontestImplementation «com.google.truth:truth:1.1.3» Entonces nuestro bloque de dependencia ahora se ve así. Avancemos y creemos una clase de prueba haciendo clic derecho en el nombre de la clase UserRepositoryImpl y seleccionando Create Test.Una vez que se crea nuestra clase, necesitamos configurar algunas variables para que podamos escribir fácilmente nuestras pruebas. Entendamos lo que hemos hecho aquí. @Antes Tenga en cuenta que hemos inicializado nuestro repositorio, clase de API y objetos de servidor simulados. Iniciamos nuestro servidor simulado y pasamos la URL base del servidor web simulado para que pueda acceder al servidor simulado y darnos la respuesta esperada. @A Tenga en cuenta que solo estamos cerrando el servidor.Diferencia entre servidor real y ficticio

Entonces, ¿por qué nos estamos burlando de un servidor? Esto se debe a que burlarse de un servidor nos daría control sobre todo tipo de respuestas y solicitudes que queremos probar en el manejo de nuestra API. Porque no hacemos pruebas en un dispositivo real y, por lo tanto, no tenemos acceso a un servidor real. Para que nuestras pruebas funcionen como se esperaba, simulamos un servidor real y MockWebServer nos permitiría hacer precisamente eso.

¡Enfriar! Ahora podemos comenzar a escribir casos de prueba. Entonces empecemos.

caso de prueba 1

Escribamos una prueba en la que queremos verificar si el servidor tiene 2 usuarios y hacemos clic en la API para obtener todos los usuarios, obtendríamos 2 usuarios con el código HTTP 200.

Realizamos esta prueba en un área de prueba porque tenemos funciones de suspensión.Filas 3-6: Primero creamos una lista de usuarios que esperamos en la respuesta del servidor.Filas 7-9: Cree una respuesta simulada para que el servidor la devuelva especificando el código HTTP y el cuerpo. Entonces, en este caso, el servidor devolverá esta respuesta sin importar qué API accedamos.linea 10: Finalmente, ponemos esta respuesta simulada en nuestro servidor.línea 12: Hemos llegado a nuestro punto final de API.linea 13: Reclamamos cuando obtenemos exactamente el mismo número de usuarios que establecemos en la respuesta de nuestro servidor. Obtenemos una verdad para eso.línea 14: Confirmamos si la lista es exactamente igual a lo que especificamos en la respuesta de nuestro servidor. Obtenemos una verdad para esto. Al ejecutar nuestro caso de prueba, obtenemos un resultado de aprobación.

caso de prueba 2

Escribamos una prueba en la que queremos verificar que si el servidor no tiene la identificación de usuario que pasamos y hacemos clic en la API obtener usuario por identificación, obtenemos el código HTTP 404 y obtendríamos un cuerpo nulo.

Línea 3-4: Cree una respuesta que esperamos en la respuesta del servidor.línea 5: Publique esta respuesta simulada en nuestro servidor.línea 7: presione obtener usuario por id api.línea 8: Reclamamos cuando recibimos exactamente el mismo código HTTP que configuramos en la respuesta de nuestro servidor. Obtenemos una verdad para eso.línea 9: Reclamamos cuando obtenemos un cuerpo nulo como lo establecemos en la respuesta de nuestro servidor. Obtenemos una verdad para eso también.

Nota: Si observamos nuestra función real getUserById, veremos que hemos manejado HttpException, donde incluimos el código http en nuestra respuesta. Por lo tanto, podemos afirmar el código http en este caso.

Al ejecutar nuestro caso de prueba, obtenemos un resultado de aprobación.¡bam! Verificamos que la configuración de nuestra API maneje las respuestas correctamente y como se esperaba. Ahora podemos continuar y escribir más casos de prueba para diferentes escenarios y confirmar si todos estos se manejan correctamente. Dejaría eso como un ejercicio para que juegues y observes el comportamiento. Avísame si te quedas atascado en algún lugar. Agregué los elementos esenciales para UserRepositoryImplTest como referencia. En caso de que desee obtener más información sobre cómo probar diferentes capas de su aplicación. Proceder al pago en los enlaces. Conéctate conmigo en Medium (si el contenido te resulta útil) o en GitHub y suscríbete a los correos electrónicos para sincronizarlos con temas más interesantes de Android/IOS/Backend/Web. Hasta la próxima… ¡Saludos!