Pruebas de repositorio con MockWebServer - 1Adevelopers/FlorAppMovil GitHub Wiki

Esta sección documenta las pruebas unitarias del repositorio de Contacto (ContactoRepository). Verifican cómo reacciona la app ante distintas respuestas del servidor sin usar el backend Django real, gracias a MockWebServer.

Dato	Valor
Herramienta	MockWebServer (`com.squareup.okhttp3:mockwebserver:4.11.0`)
Lenguaje / framework	Java + JUnit 4
Tipo de prueba	Unitaria (corre en la PC, sin celular ni emulador)
Clase probada	`com.ispc.florappmovil.data.ContactoRepository`
Clase de test	`app/src/test/java/com/ispc/florappmovil/data/ContactoRepositoryTest.java`
Endpoint involucrado	`POST api/interacciones/` (formulario de contacto)
Responsable	Eric Heredia
Reporte	ContactoRepositoryTest ContactoViewModelTest

1. ¿Qué es MockWebServer?

MockWebServer es un servidor HTTP falso que se enciende dentro del test, en la propia PC. Antes de cada prueba se le indica qué debe responder (por ejemplo 200 OK o 500 Internal Server Error) y luego se verifica que la app reaccione correctamente.

ContactoRepositoryTest ──► ContactoRepository ──► Retrofit ──► MockWebServer (servidor falso en la PC)
   "respondé 500"            envía el formulario      POST          responde lo que le indicó el test

Ventajas frente a probar contra Django:

Con el backend real	Con MockWebServer
Hay que encender Django y MySQL	No necesita nada encendido
Es difícil forzar un error 500	Se elige la respuesta exacta (200, 400, 500…)
El resultado depende de la red y los datos	Resultado siempre igual (repetible)
Más lento	Se ejecuta en menos de 1 segundo

2. Capa probada: el repositorio

El repositorio es la clase que se comunica con el servidor. Las pantallas (o el ViewModel) le piden los datos y no necesitan saber cómo se obtienen.

En Contacto quedan cubiertas las dos capas:

Capa	Test	Cómo simula el servidor
ViewModel	`ContactoViewModelTest` (AUT-UNIT-02 / 03)	Mockito: repositorio simulado
Repositorio	`ContactoRepositoryTest` (AUT-UNIT-04 / 05)	MockWebServer: servidor HTTP falso

Cambio realizado en `ContactoRepository`

Antes devolvía siempre true sin llamar al servidor. Ahora realiza el envío real:

ContactoRepository(): constructor que usa la app; se conecta al backend configurado en RetrofitClient.
ContactoRepository(FlorAppApi api): constructor para los tests; recibe una API que apunta a MockWebServer.
enviarMensajeContacto(nombre, email, mensaje): envía POST api/interacciones/ y devuelve:
- true si el servidor responde 2xx (200 / 201),
- false si responde con error (400, 500…),
- lanza una excepción si no se puede conectar.

Es una llamada sincrónica (execute()): en la app debe llamarse fuera del hilo principal.

3. Pruebas implementadas

ID automatización	Método	Respuesta simulada	Qué verifica
AUT-UNIT-04	`enviarMensajeContacto_respuesta200_devuelveTrue`	`200 OK`	Devuelve `true`; la petición fue `POST` a `/api/interacciones/` y el cuerpo incluye el email enviado
AUT-UNIT-05	`enviarMensajeContacto_respuesta500_devuelveFalse`	`500 Internal Server Error`	Devuelve `false`; se realizó una sola petición

Estructura de cada test (Arrange – Act – Assert)

Momento	Qué hace
`@Before`	Enciende MockWebServer y crea Retrofit + `ContactoRepository` apuntando a él
Arrange	Encola la respuesta: `servidor.enqueue(new MockResponse().setResponseCode(200))`
Act	Llama a `repositorio.enviarMensajeContacto(...)`
Assert	Verifica el resultado (`true` / `false`) y la petición recibida (`takeRequest()`)
`@After`	Apaga el servidor (`servidor.shutdown()`)

4. Configuración

En app/build.gradle, dentro de dependencies:

testImplementation 'com.squareup.okhttp3:mockwebserver:4.11.0'

Se usa la versión 4.11.0 para coincidir con la versión de OkHttp que ya usa el proyecto (logging-interceptor:4.11.0). Es testImplementation: solo se usa en los tests y no se incluye en la app.

Después de agregarla: Sync Now en Android Studio.

5. Ejecutar las pruebas

No hace falta encender Django ni conectar el celular.

Desde Android Studio

Abrir ContactoRepositoryTest y tocar el ▶ verde junto a la clase → Run 'ContactoRepositoryTest'.

Desde la terminal (raíz del proyecto)

Solo estas pruebas:

.\gradlew.bat :app:testDebugUnitTest --tests "*ContactoRepositoryTest"

Todas las pruebas unitarias de la app:

.\gradlew.bat :app:cleanTestDebugUnitTest :app:testDebugUnitTest

En Git Bash usar ./gradlew en lugar de .\gradlew.bat.

Informe HTML

app/build/reports/tests/testDebugUnitTest/index.html

Abrirlo con start app\build\reports\tests\testDebugUnitTest\index.html (PowerShell) o con doble clic desde el Explorador de Windows.

6. Resultado de la ejecución

Fecha	Ambiente	Resultado
13/10/2026	Windows – Android Studio – JUnit 4 (JVM local)	✅ 2 de 2 tests aprobados (669 ms)

Además se verificó que los tests existentes (ContactoViewModelTest, ContactoValidadorTest) siguen pasando con el repositorio modificado.

7. Problemas frecuentes

Síntoma	Causa probable y solución
`MockWebServer` o `MockResponse` en rojo	Falta la dependencia o el Sync Now. Revisar `app/build.gradle`.
`Cannot resolve symbol` en clases de la app	La clase de test quedó en `androidTest` o en `main`. Debe estar en `app/src/test/java/...` (carpeta (test)).
`java.lang.NoSuchMethodError` de OkHttp	Versión de MockWebServer distinta a la de OkHttp. Usar la misma versión (4.11.0).
La terminal no reconoce `gradlew.bat`	En PowerShell se escribe con `.\` adelante: `.\gradlew.bat`.

8. Cómo agregar otro test

Agregar un método @Test en ContactoRepositoryTest.
Encolar la respuesta a simular, por ejemplo un error de validación:
```
servidor.enqueue(new MockResponse().setResponseCode(400));
```
Llamar al repositorio y verificar el resultado con assertTrue / assertFalse / assertEquals.
Registrar el ID en la planilla de casos de prueba (columna "Herramienta e ID del test"), por ejemplo: MockWebServer + JUnit – AUT-UNIT-06 (ContactoRepositoryTest.enviarMensajeContacto_respuesta400_devuelveFalse)