Curso sobre gestión de CORS y pruebas - Creación de una API de ejemplo en C#

Cómo configurar el frontend de Blazor

Tim comienza la lección con la creación de un sencillo proyecto frontend Blazor WebAssembly llamado SampleTestUI. Esta interfaz no está lista para la producción, sino que se trata de un proyecto de prueba para verificar la conectividad con la API y provocar intencionadamente un problema de CORS.

• Tim utiliza la plantilla .NET 9 y no incluye funciones de autenticación ni PWA.

• El propósito del frontend es simular llamadas a API del mundo real y exponer fallos de prueba relacionados con solicitudes de origen cruzado.

• Modifica la página de inicio para llamar al punto final de la API /courses y mostrar una lista de cursos con imágenes asociadas.

El frontend utiliza una clase de modelo simple (CourseModel) creada por separado, en lugar de compartir el modelo con la API. Tim hace hincapié en que los modelos frontales deben estar separados de los modelos de acceso a datos para reducir el acoplamiento y aumentar la capacidad de mantenimiento (2:28). Este es un principio importante a la hora de escribir pruebas mantenibles y código comprobable.

Escribir la llamada a la API

Para obtener datos de la API:

• Tim inyecta un HttpClient.

• Escribe un método asíncrono utilizando Http.GetFromJsonAsync<List>().

• El método está codificado con la URL de la API local (4:00), que sirve como prueba sencilla para validar la comunicación entre el frontend y el backend.

Aquí no hay métodos de prueba ni tratamiento de errores, solo una llamada directa. Esta configuración refleja los primeros pasos en la escritura de pruebas unitarias, donde se empieza por validar la interacción básica entre los componentes.

Construcción de la lógica de obtención de datos y la interfaz de usuario

Después de codificar la URL de la API a las 4:00, Tim se centra en la construcción de la lógica central para obtener los datos del curso de la API y mostrarlos en el frontend de Blazor. Se trata de un paso crucial para validar que el frontend puede interactuar con el backend, incluso antes de escribir pruebas automáticas o utilizar un marco de pruebas.

En primer lugar, se asegura de que se utiliza la URL correcta del archivo launchSettings.json de la API, tomando la dirección HTTPS y añadiendo /courses para formar el punto final completo. Esto es importante porque los navegadores suelen rechazar las llamadas a API no HTTPS desde páginas seguras.

courses = await Http.GetFromJsonAsync<List<CourseModel>>("https://localhost:port/courses");

courses = await Http.GetFromJsonAsync<List<CourseModel>>("https://localhost:port/courses");

Visualización de los datos

Una vez obtenidos los datos, Tim escribe un sencillo bucle de interfaz de usuario utilizando la sintaxis Razor para recorrer la lista de cursos:

@foreach (var c in courses) { <a href="@c.CourseUrl"> <img width="300" src="@c.CourseImage" /> </a> }

@foreach (var c in courses) { <a href="@c.CourseUrl"> <img width="300" src="@c.CourseImage" /> </a> }

Cada curso se muestra como una imagen envuelta en un hipervínculo. Tim señala que las imágenes son grandes (1920x1080), por lo que limita la anchura a 300px para evitar abrumar la página.

Este resultado sirve de confirmación visual de que los datos de la API fluyen correctamente hacia el frontend. Imita el tipo de respuesta que se espera de un método de prueba: si aparecen las imágenes, la solicitud se ha realizado correctamente.

Preparación para el lanzamiento

Antes de ejecutar la aplicación, Tim configura varios proyectos de inicio en Visual Studio. Establece que el proyecto de la API se inicie en primer lugar, seguido del frontend de Blazor. Este orden es esencial para garantizar que la API esté lista en el momento en que el frontend intente obtener los datos.

Este paso final a las 6:30 prepara el escenario para ejecutar la prueba y encontrar el error CORS, que es donde comienza la siguiente parte del tutorial.

Golpeando el muro de CORS

Cuando Tim inicia ambos proyectos simultáneamente mediante el explorador de soluciones de Visual Studio, el frontend intenta llamar a la API, pero no lo consigue. La consola del navegador muestra un mensaje familiar:

"Access to fetch at '[API URL]' from origin '[Frontend URL]' has been blocked by CORS policy..."(7:02)

Aquí es donde resulta esencial comprender y gestionar CORS. Sin las cabeceras adecuadas, el navegador bloquea las peticiones de un origen a otro.

Creación de una clase de configuración CORS

En lugar de desordenar Program.cs, Tim crea una clase dedicada llamada CorsConfig en una carpeta de inicio. Utiliza una estructura de clases estáticas para aplicar el mismo patrón de configuración utilizado para la configuración de Swagger y OpenAPI.

Esto se alinea con las prácticas de código limpio y hace que la aplicación sea más comprobable. Las configuraciones modulares de este tipo también facilitan la escritura posterior de métodos de pruebas unitarias, ya que la lógica está aislada y es más fácil de imitar o anular.

Aplicación de una política CORS permisiva

Tim define una política CORS muy abierta para permitir un acceso completo entre orígenes:

policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();

policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();

Esta configuración es útil en el desarrollo basado en pruebas y en las pruebas de integración, en las que los servicios externos o las aplicaciones frontales necesitan acceso completo a la API. Tim llama a esta política "AllowAll" y almacena el nombre en una constante para evitar errores tipográficos e incoherencias (11:00):

private const string AllowAllPolicy = "AllowAll";

private const string AllowAllPolicy = "AllowAll";

Señala que esto no debe utilizarse en producción, pero es ideal para probar API localmente o dentro de contenedores Docker donde los desarrolladores están experimentando o escribiendo pruebas unitarias contra puntos finales reales.

Integración de la configuración en Program.cs

Tim registra los servicios CORS y aplica la configuración en Program.cs:

builder.Services.AddCorsServices(); app.ApplyCorsConfig();

builder.Services.AddCorsServices(); app.ApplyCorsConfig();

Esta modularidad mejora la calidad del código y facilita la adición de marcos de simulación o la inyección de comportamientos de prueba en el futuro. Refleja cómo se estructurarían las cosas para las pruebas unitarias en C#, donde tener configuraciones centralizadas puede simplificar la configuración de las pruebas.

Prueba del frontend

Tras aplicar la corrección CORS, Tim vuelve a ejecutar ambas aplicaciones. Esta vez, la interfaz de Blazor funciona como se esperaba: los datos del curso se cargan correctamente y cada imagen del curso enlaza con la URL correspondiente.

Es importante destacar que no se han realizado cambios en el frontend. Toda la corrección se produjo a nivel de la API, mediante una configuración CORS adecuada.

Lecciones de estrategia de pruebas y configuración

Aunque Tim no se sumerge directamente en los marcos de pruebas unitarias en este vídeo, su enfoque sienta las bases para ello. Así es como:

• Separa las preocupaciones limpiamente, permitiendo el uso de clases de prueba y objetos simulados en el futuro.

• El archivo de configuración CORS dedicado podría reutilizarse o sustituirse por una configuración simulada durante las pruebas.

• Su proyecto de frontend rápido actúa como una prueba de integración manual, una validación temprana antes de escribir proyectos completos de pruebas unitarias.

Esto refleja cómo se abordan las pruebas en Visual Studio:

• Crea un proyecto de pruebas unitarias junto con tu aplicación principal.

• Utilice Test Explorer para ejecutar todos los métodos de prueba y realizar un seguimiento de los resultados.

• Simule dependencias externas como peticiones HTTP, llamadas a bases de datos o archivos de configuración.

• Escriba pruebas unitarias sencillas para validar el comportamiento esperado y, a continuación, amplíelas para abarcar casos de prueba con condiciones límite.

Consideraciones de pruebas unitarias para escenarios CORS

Aunque el vídeo de Tim trata principalmente sobre la configuración de CORS, las implicaciones para las pruebas de software son claras:

• Puede crear métodos de prueba unitarios que validen sus servicios de configuración.

• Utilizando marcos de simulación, simule factores externos como diferentes orígenes o métodos HTTP.

• Realice ejecuciones de prueba como parte de su proceso CI/CD para confirmar que sus métodos de prueba pasan de forma consistente.

• Incorpore pruebas al Explorador de pruebas de Visual Studio para realizar un seguimiento de los fallos y garantizar la estabilidad.

Conclusión

En este tutorial vídeo, Tim Corey ofrece un ejemplo práctico de la gestión de CORS en una API web en C# mientras construye un sencillo frontend Blazor para probar la conectividad. Su enfoque no se limita a corregir un error del navegador, sino que establece una estructura que fomenta un código mantenible, una arquitectura limpia y una fácil extensión a las pruebas automatizadas.

A partir de aquí, los desarrolladores pueden avanzar con confianza en la escritura de pruebas unitarias, la configuración de pruebas de integración, y el uso de herramientas como Visual Studio, Test Explorer, y marcos de simulación para mejorar la calidad del código y la fiabilidad.

Tanto si quieres aprender cómo empezar a realizar pruebas, escribir tu primera prueba unitaria o asegurarte de que los métodos de prueba fallan cuando se espera, esta lección proporciona las bases para un proceso de desarrollo sólido. Y lo que es más importante: todo empieza por entender bien la arquitectura y la configuración.