Gestion des CORS et des tests - Construction d'un exemple d'API en C# Course

Mise en place du Frontend Blazor

Tim commence la leçon en créant un simple projet frontal Blazor WebAssembly nommé SampleTestUI. Ce frontend n'est pas prêt pour la production. Il s'agit plutôt d'un projet de test visant à vérifier la connectivité avec l'API et à déclencher intentionnellement un problème CORS.

• Tim utilise le modèle .NET 9 et renonce aux fonctions d'authentification ou de PWA.

• L'objectif du frontend est de simuler des appels d'API réels et d'exposer les échecs des tests liés aux demandes d'origine croisée.

• Il modifie la page d'accueil pour appeler le point de terminaison API /courses et afficher une liste de cours avec les images associées.

Le frontend utilise une classe de modèle simple (CourseModel) créée séparément, plutôt que de partager le modèle avec l'API. Tim insiste sur le fait que les modèles frontaux doivent être séparés des modèles d'accès aux données afin de réduire le couplage et d'améliorer la maintenabilité (2:28). Il s'agit d'un principe important pour l'écriture de tests et de codes faciles à maintenir.

Écrire l'appel d'API

Pour récupérer des données de l'API :

• Tim injecte un HttpClient.

• Il écrit une méthode asynchrone en utilisant Http.GetFromJsonAsync<List>().

• La méthode est codée en dur avec l'URL de l'API locale (4:00), servant de test simple pour valider la communication entre le frontend et le backend.

Il n'y a pas de méthode de test ou de gestion des erreurs ici, juste un appel direct. Cette configuration reflète les premières étapes de l'écriture de tests unitaires, où l'on commence par valider l'interaction de base entre les composants.

Construction de la logique de récupération des données et de l'interface utilisateur

Après avoir codé en dur l'URL de l'API à 4:00, Tim se concentre sur la construction de la logique de base pour récupérer les données de cours de l'API et les afficher dans le frontend de Blazor. Il s'agit d'une étape cruciale pour valider que le frontend peut interagir avec le backend, avant même d'écrire des tests automatisés ou d'utiliser un cadre de test.

Tout d'abord, il s'assure que l'URL correcte est utilisée à partir du fichier launchSettings.json de l'API - en saisissant l'adresse HTTPS et en ajoutant /courses pour former le point de terminaison complet. Ceci est important car les navigateurs rejettent souvent les appels API non-HTTPS à partir de pages sécurisées.

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

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

Afficher les données

Une fois les données récupérées, Tim écrit une simple boucle d'interface utilisateur utilisant la syntaxe Razor pour parcourir la liste des cours :

@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> }

Chaque cours est présenté sous la forme d'une image entourée d'un lien hypertexte. Tim note que les images sont de grande taille (1920x1080), il limite donc la largeur à 300px pour éviter de surcharger la page.

Cette sortie sert de confirmation visuelle que les données de l'API sont correctement transférées dans le frontend. Elle imite le type de retour d'information que l'on attend d'une méthode de test qui passe : si les images apparaissent, la requête a réussi.

Préparation du lancement

Avant d'exécuter l'application, Tim configure plusieurs projets de démarrage dans Visual Studio. Il configure le projet API pour qu'il démarre en premier, suivi par le frontend Blazor. Cette commande est essentielle pour s'assurer que l'API est prête au moment où le frontend tente de récupérer les données.

Cette dernière étape à 6:30 prépare le terrain pour l'exécution du test et la rencontre de l'erreur CORS, qui est le point de départ de la partie suivante du didacticiel.

Faire face au mur CORS

Lorsque Tim lance les deux projets simultanément à l'aide de l'explorateur de solutions de Visual Studio, le frontend tente d'appeler l'API, mais n'y parvient pas. La console du navigateur affiche un message familier :

"L'accès à '\N[API URL]' depuis l'origine '\N[Frontend URL]' a été bloqué par la politique CORS..."(7:02)

C'est là que la compréhension et la gestion de CORS deviennent essentielles. En l'absence d'en-têtes appropriés, le navigateur bloque les requêtes d'une origine à une autre.

Création d'une classe de configuration CORS

Plutôt que d'encombrer Program.cs, Tim crée une classe dédiée nommée CorsConfig dans un dossier Startup. Il utilise une structure de classe statique pour appliquer le même modèle de configuration que celui utilisé pour Swagger et OpenAPI.

Elle s'aligne sur les pratiques de code propre et rend l'application plus testable. Les configurations modulaires de ce type facilitent également l'écriture ultérieure de méthodes de test unitaire, car la logique est isolée et plus facile à simuler ou à remplacer.

Application d'une politique CORS permissive

Tim définit une politique CORS très ouverte pour permettre un accès inter-origines complet :

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

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

Cette configuration est utile pour le développement piloté par les tests et les tests d'intégration, lorsque des services externes ou des applications frontales ont besoin d'un accès complet à l'API. Tim appelle cette politique "AllowAll" et enregistre le nom dans une constante pour éviter les fautes de frappe et les incohérences (11:00) :

private const string AllowAllPolicy = "AllowAll";

private const string AllowAllPolicy = "AllowAll";

Il précise que ces outils ne doivent pas être utilisés en production, mais qu'ils sont idéaux pour tester les API localement ou dans des conteneurs Docker où les développeurs expérimentent ou écrivent des tests unitaires contre des points de terminaison réels.

Intégration de la configuration dans Program.cs

Tim enregistre les services CORS et applique la configuration dans Program.cs :

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

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

Cette modularité améliore la qualité du code et facilite l'ajout de cadres de simulation ou l'injection de comportements de test à l'avenir. Elle reflète la façon dont vous structureriez les choses pour les tests unitaires en C#, où le fait d'avoir des configurations centralisées peut simplifier la mise en place des tests.

Retester le Frontend

Après avoir appliqué la correction CORS, Tim relance les deux applications. Cette fois-ci, le frontend de Blazor fonctionne comme prévu : les données des cours se chargent correctement et chaque image de cours renvoie à l'URL correspondante.

Il est important de noter qu'aucune modification n'a été apportée à l'interface utilisateur. L'ensemble de la correction s'est produit au niveau de l'API, grâce à une configuration CORS appropriée.

Les leçons de test et de stratégie d'installation

Bien que Tim n'aborde pas directement les cadres de test unitaire dans cette vidéo, son approche en pose les bases. Voici comment :

• Il sépare proprement les préoccupations, ce qui permettra à l'avenir d'utiliser des classes de test et des objets fictifs.

• Le fichier de configuration CORS dédié pourrait être réutilisé ou remplacé par une configuration fictive pendant les tests.

• Son projet frontal rapide agit comme un test d'intégration manuel - une validation précoce avant d'écrire des projets de test d'unité complets.

Cela reflète la façon dont vous abordez les tests dans Visual Studio :

• Créez un projet de test unitaire parallèlement à votre application principale.

• Utilisez Test Explorer pour exécuter toutes les méthodes de test et suivre les résultats.

• Simuler des dépendances externes telles que des requêtes HTTP, des appels de base de données ou des fichiers de configuration.

• Rédigez des tests unitaires simples pour valider le comportement attendu, puis élargissez-les pour couvrir les cas de test avec des conditions marginales.

Considérations sur les tests unitaires pour les scénarios CORS

Bien que la vidéo de Tim porte principalement sur la configuration de CORS, les implications pour les tests de logiciels sont claires :

• Vous pouvez créer des méthodes de test unitaire qui valident vos services de configuration.

• À l'aide de cadres de simulation, simulez des facteurs externes tels que différentes origines ou méthodes HTTP.

• Exécutez des tests dans le cadre de votre processus CI/CD pour confirmer que vos méthodes de test sont toujours efficaces.

• Incorporez des tests dans l'explorateur de tests de Visual Studio afin de garder une trace des échecs et de garantir la stabilité.

Conclusion

Dans ce tutoriel vidéo, Tim Corey propose un exemple pratique de gestion de CORS dans une API Web C# tout en construisant un simple frontend Blazor pour tester la connectivité. Son approche ne se limite pas à la correction d'une erreur de navigateur : elle met en place une structure qui encourage la maintenance du code, une architecture propre et une extension facile des tests automatisés.

À partir de là, les développeurs peuvent passer en toute confiance à l'écriture de tests unitaires, à la mise en place de tests d'intégration et à l'utilisation d'outils tels que Visual Studio, Test Explorer et les frameworks de mocking afin d'améliorer la qualité et la fiabilité du code.

Que vous appreniez à démarrer les tests, à écrire votre premier test unitaire ou à vous assurer que les méthodes de test échouent comme prévu, cette leçon jette les bases d'un processus de développement solide. Et surtout, tout commence par une architecture et une configuration correctes.