La lección anterior ensambló la API completa de BiblioTech sobre el dominio, la persistencia y la inyección de dependencias ya construidos. Antes de desplegar nada (Lección 5), hace falta verificar que esa API funciona de verdad de principio a fin, no solo que cada pieza suelta pasaba sus pruebas unitarias por separado. Esta lección amplía la batería de pruebas del Módulo 8 con pruebas de integración sobre los endpoints, repasa las técnicas de depuración más útiles en Visual Studio y VS Code, introduce el registro de eventos (logging) con ILogger para diagnosticar problemas ya en producción, y cierra con un checklist de calidad concreto que debe superarse antes de avanzar a la Lección 5.

1. Pruebas unitarias frente a pruebas de integración
2. Pruebas de integración con WebApplicationFactory
3. Depuración en Visual Studio y VS Code: breakpoints y watch
4. Depuración de código asíncrono
5. Logging básico con ILogger
6. Checklist de calidad antes de desplegar

Las pruebas unitarias del Módulo 8 (Lección 4) verificaban una unidad aislada de código —un método de Prestamo, o Biblioteca.PrestarLibroAsync con un mock de IRepositorioBiblioteca— sin necesitar nada externo. Una prueba de integración verifica, en cambio, que varias piezas reales trabajando juntas producen el resultado esperado: en el caso de BiblioTech, que una petición HTTP real, a través del enrutamiento real de ASP.NET Core, con el contenedor de DI real resolviendo las dependencias reales, produce la respuesta correcta.

Ninguna sustituye a la otra: las pruebas unitarias siguen siendo la base más rápida y numerosa (Módulo 8), y las pruebas de integración añaden una capa de confianza distinta, más cercana a cómo un cliente real usará la API.

ASP.NET Core ofrece WebApplicationFactory<TEntryPoint>, una clase pensada para arrancar la aplicación completa en memoria, sin necesitar un puerto de red real ni un despliegue, y obtener un HttpClient (el mismo tipo ya usado en el Módulo 5) que dirige sus peticiones directamente a esa aplicación en memoria:

IClassFixture<WebApplicationFactory<Program>> le dice a xUnit que comparta una única instancia de la aplicación en memoria entre todas las pruebas de esta clase, en vez de arrancarla de nuevo en cada método (mucho más rápido). PostAsJsonAsync serializa solicitud a JSON automáticamente con System.Text.Json (Módulo 5), exactamente igual que haría un cliente real contra la API desplegada. Estas pruebas complementan, sin sustituir, las pruebas unitarias de Moq de 08-04: verifican que el endpoint HTTP realmente enruta, deserializa y responde como se espera, algo que un mock de IRepositorioBiblioteca no puede comprobar por sí solo.

Cuando una prueba falla o el comportamiento observado no coincide con el esperado, la depuración permite detener la ejecución en un punto concreto e inspeccionar el estado del programa en ese instante, en vez de adivinar qué ocurre a partir de mensajes de consola:

Un flujo típico de depuración sobre POST /prestamos/{id}/devolucion (09-03, apartado 6): colocar un breakpoint en la línea prestamo.RegistrarDevolucion();, lanzar la API en modo depuración (F5 en Visual Studio o VS Code), hacer la petición real con Swagger o curl, y cuando la ejecución se detenga, inspeccionar en el Watch el valor de prestamo.FechaPrestamo y politica.CalcularSancion(...) antes de que se ejecuten, para confirmar que los datos que llegan son los esperados.

Depurar métodos async/await (Módulo 4) tiene una particularidad: al hacer Step Into sobre un await, la ejecución puede "saltar" de forma que parezca que el hilo cambia, porque efectivamente puede reanudarse en un hilo distinto tras la espera (Módulo 6, multihilo). Algunas prácticas ayudan a que esto no confunda:

• Colocar el breakpoint después del await (por ejemplo, justo donde se usa el resultado de ObtenerMetadatosPorIsbnAsync) para inspeccionar el valor ya resuelto, en vez de intentar seguir la espera misma paso a paso.
• Revisar la pila de llamadas con atención tras un await: puede mostrarse más corta de lo esperado, porque parte de la pila "anterior" a la espera ya no existe de la misma forma una vez que el método se reanuda.
• Para el Task.Delay(1000) de PrestarLibroAsync (08-04), un breakpoint justo después de esa línea permite confirmar que la ejecución efectivamente esperó, sin necesidad de depurar la espera en sí misma paso a paso.

Los breakpoints son la herramienta adecuada mientras se desarrolla y se puede reproducir el problema localmente. En producción (Lección 5), no hay forma de detener la ejecución con un breakpoint: la herramienta equivalente es el logging, mensajes que el programa escribe de forma continua describiendo lo que va haciendo, para poder revisarlos después si algo falla. ASP.NET Core inyecta automáticamente un ILogger<T> en cualquier clase que lo declare por constructor (08-03, inyección por constructor):

Los marcadores {Id} y {Sancion:C} en el mensaje no son interpolación de cadenas de C# ($"..."): son parámetros con nombre que el proveedor de logging estructura por separado del texto, lo que permite después buscar o filtrar registros por Id sin tener que analizar el texto del mensaje. Por defecto, ASP.NET Core escribe estos mensajes en la consola durante el desarrollo; en producción (Lección 5) se configuran proveedores adicionales (ficheros, servicios de monitorización) sin cambiar ni una línea de las llamadas a logger.LogInformation(...).

Antes de pasar a la Lección 5 (Despliegue), este checklist reúne lo verificado en esta lección con lo ya visto en 08-05:

• [ ] Todas las pruebas unitarias del Módulo 8 (Prestamo, Biblioteca.PrestarLibroAsync) están en verde.
• [ ] Las nuevas pruebas de integración del apartado 2 sobre los endpoints principales están en verde.
• [ ] El analizador de código del proyecto no reporta advertencias sin justificar (dotnet build sin warnings, o cada uno explícitamente revisado).
• [ ] La checklist de revisión de 08-05 (nomenclatura, dependencias inyectadas, nulabilidad consistente) se ha aplicado sobre el código nuevo de 09-03.
• [ ] Los endpoints que pueden fallar por causas esperadas (préstamo no disponible, socio no encontrado, metadatos externos no disponibles) devuelven un código HTTP y un mensaje claros, no un error 500 genérico.
• [ ] Se ha añadido logging (ILogger) al menos en los puntos donde algo puede fallar por causas externas (persistencia, consulta de metadatos).

Superar este checklist no es una formalidad burocrática: es la confirmación concreta de que la API está lista para el paso siguiente, mucho más arriesgado si algo de esto faltara: publicarla fuera del entorno de desarrollo.

• Confundir una prueba de integración con una prueba manual: una prueba de integración debe poder ejecutarse automáticamente con dotnet test, igual que una prueba unitaria; probar la API a mano con Swagger es útil durante el desarrollo, pero no sustituye a una prueba automatizada que se repita en cada cambio.
• Usar interpolación de cadenas ($"...") en llamadas a ILogger: pierde la estructura de los parámetros con nombre (apartado 5), dificultando buscar o filtrar registros después; usa siempre los marcadores {NombreParametro} con los valores como argumentos adicionales.
• Depurar en producción con breakpoints: no es una opción real (no hay forma de "detener" un servidor en producción sin interrumpir a los usuarios); el logging del apartado 5 es la herramienta pensada exactamente para ese escenario.
• Consejo: si una prueba de integración falla de forma intermitente (a veces pasa, a veces no), sospecha primero de dependencias de tiempo real (como el Task.Delay de PrestarLibroAsync) o de estado compartido entre pruebas que no se limpia correctamente entre una y otra.

1. Escribe una prueba de integración PostSocios_ConSocioValido_Devuelve201 que haga un POST a /socios con un Socio válido y compruebe que la respuesta tiene código 201 Created.

2. Añade una llamada a logger.LogError en el catch (InvalidOperationException ex) del endpoint POST /prestamos de 09-03, registrando el mensaje de la excepción antes de devolver Results.Conflict(ex.Message).

[Fact]
public async Task PostSocios_ConSocioValido_Devuelve201()
{
    // Arrange
    Socio socio = new Socio(99, "Marta Ruiz");

    // Act
    HttpResponseMessage respuesta = await _cliente.PostAsJsonAsync("/socios", socio);

    // Assert
    Assert.Equal(HttpStatusCode.Created, respuesta.StatusCode);
}

try
{
    await biblioteca.PrestarLibroAsync(libro, socio);
}
catch (InvalidOperationException ex)
{
    logger.LogError(ex, "Fallo al registrar el prestamo para el ISBN {Isbn}", solicitud.Isbn);
    return Results.Conflict(ex.Message);
}

(Nota: esta versión requiere añadir ILogger<Program> logger como parámetro adicional del endpoint, igual que en el ejemplo del apartado 5; logger.LogError(ex, ...) registra además la excepción completa, no solo el mensaje.)

Esta lección ha ampliado la confianza en BiblioTech más allá de las pruebas unitarias del Módulo 8: ahora existen también pruebas de integración con WebApplicationFactory que verifican los endpoints reales de principio a fin, se han repasado las técnicas de depuración —incluida la particularidad de depurar código asíncrono—, se ha añadido logging con ILogger para diagnosticar problemas una vez desplegada la aplicación, y se ha fijado un checklist de calidad concreto. Con todos esos puntos superados, BiblioTech está lista, por fin, para el paso que cierra el proyecto y el curso entero: la lección final, Despliegue, publicará esta API, la contenedorizará con Docker, y configurará su comportamiento por entorno para producción.