Verwalten von CORS und Testen - Erstellen einer Beispiel-API in C# Kurs

Einrichten des Blazor-Frontends

Tim beginnt die Lektion mit der Erstellung eines einfachen Blazor WebAssembly-Frontend-Projekts namens SampleTestUI. Dieses Frontend ist nicht produktionsreif, sondern ein Testprojekt, um die Konnektivität mit der API zu überprüfen und absichtlich ein CORS-Problem auszulösen.

• Tim verwendet die .NET 9-Vorlage und verzichtet auf Authentifizierungs- oder PWA-Funktionen.

• Der Zweck des Frontends besteht darin, reale API-Aufrufe zu simulieren und Testfehler im Zusammenhang mit herkunftsübergreifenden Anfragen aufzudecken.

• Er modifiziert die Homepage, um den API-Endpunkt /courses aufzurufen und eine Liste von Kursen mit zugehörigen Bildern anzuzeigen.

Das Frontend verwendet eine einfache Modellklasse (CourseModel), die separat erstellt wurde, anstatt das Modell mit der API zu teilen. Tim betont, dass Frontend-Modelle von Datenzugriffsmodellen getrennt sein sollten, um die Kopplung zu reduzieren und die Wartbarkeit zu erhöhen (2:28). Dies ist ein wichtiger Grundsatz beim Schreiben von wartbaren Tests und testbarem Code.

Schreiben des API-Aufrufs

Um Daten von der API abzurufen:

• Tim fügt einen HttpClient ein.

• Er schreibt eine asynchrone Methode mit Http.GetFromJsonAsync<List>().

• Die Methode ist mit der lokalen API-URL fest kodiert (4:00) und dient als einfacher Test, um die Kommunikation zwischen dem Frontend und dem Backend zu überprüfen.

Es gibt hier keine Testmethode oder Fehlerbehandlung, nur einen einfachen Aufruf. Dieser Aufbau spiegelt die ersten Schritte beim Schreiben von Unit-Tests wider, bei denen Sie mit der Validierung der grundlegenden Interaktion zwischen Komponenten beginnen.

Aufbau der Datenabruflogik und der Benutzeroberfläche

Nach der Hardcodierung der API-URL um 4:00 Uhr konzentriert sich Tim auf die Erstellung der Kernlogik, um Kursdaten von der API abzurufen und sie im Blazor-Frontend anzuzeigen. Dies ist ein entscheidender Schritt bei der Validierung, dass das Frontend mit dem Backend interagieren kann, noch bevor automatisierte Tests geschrieben oder ein Test-Framework verwendet wird.

Zunächst stellt er sicher, dass die richtige URL aus der launchSettings.json der API verwendet wird, indem er die HTTPS-Adresse abgreift und /courses anhängt, um den vollständigen Endpunkt zu bilden. Dies ist wichtig, da Browser häufig nicht-HTTPS-API-Aufrufe von sicheren Seiten ablehnen.

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

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

Anzeigen der Daten

Sobald die Daten abgerufen sind, schreibt Tim eine einfache UI-Schleife mit Razor-Syntax, um die Kursliste zu durchlaufen:

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

Jeder Kurs wird als Bild mit einem Hyperlink dargestellt. Tim merkt an, dass die Bilder groß sind (1920x1080), so dass er die Breite auf 300px begrenzt, um die Seite nicht zu überladen.

Diese Ausgabe dient als visuelle Bestätigung, dass die API-Daten korrekt in das Frontend fließen. Sie ahmt die Art von Feedback nach, die man sich von einer bestandenen Testmethode wünschen würde - wenn die Bilder angezeigt werden, war die Anfrage erfolgreich.

Vorbereitungen für die Markteinführung

Bevor die Anwendung ausgeführt wird, konfiguriert Tim mehrere Startprojekte in Visual Studio. Er legt fest, dass zuerst das API-Projekt und dann das Blazor-Frontend beginnen soll. Diese Reihenfolge ist wichtig, um sicherzustellen, dass die API fertig ist, wenn das Frontend versucht, Daten abzurufen.

Dieser letzte Schritt um 6:30 Uhr schafft die Voraussetzungen für die Durchführung des Tests und das Auftreten des CORS-Fehlers, womit der nächste Teil des Lernprogramms beginnt.

Gegen die CORS-Mauer

Als Tim beide Projekte gleichzeitig über den Projektmappen-Explorer von Visual Studio startet, versucht das Frontend, die API aufzurufen, was jedoch fehlschlägt. Die Konsole des Browsers zeigt eine bekannte Meldung an:

"Der Zugriff auf den Abruf von '[API-URL]' vom Ursprung '[Frontend-URL]' wurde durch CORS-Richtlinien blockiert..."(7:02)

An dieser Stelle wird das Verständnis und die Verwaltung von CORS unerlässlich. Ohne die richtigen Header blockiert der Browser Anfragen von einem Ursprung zum anderen.

Erstellen einer CORS-Konfigurationsklasse

Anstatt die Datei Program.cs zu überladen, erstellt Tim eine eigene Klasse namens CorsConfig in einem Startup-Ordner. Er verwendet eine statische Klassenstruktur, um das gleiche Konfigurationsmuster anzuwenden, das für die Einrichtung von Swagger und OpenAPI verwendet wird.

Dies steht im Einklang mit den Praktiken für sauberen Code und macht die Anwendung besser testbar. Modulare Konfigurationen wie diese machen es auch einfacher, später Unit-Test-Methoden zu schreiben, da die Logik isoliert ist und leichter nachgeahmt oder außer Kraft gesetzt werden kann.

Anwendung einer permissiven CORS-Richtlinie

Tim definiert eine sehr offene CORS-Richtlinie, um einen vollständigen herkunftsübergreifenden Zugriff zu ermöglichen:

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

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

Dieses Setup ist nützlich für die testgetriebene Entwicklung und Integrationstests, bei denen externe Dienste oder Frontend-Anwendungen vollen Zugriff auf die API benötigen. Tim nennt diese Richtlinie "AllowAll" und speichert den Namen in einer Konstante, um Tippfehler und Inkonsistenzen zu vermeiden (11:00):

private const string AllowAllPolicy = "AllowAll";

private const string AllowAllPolicy = "AllowAll";

Er weist darauf hin, dass dies nicht in der Produktion verwendet werden sollte, aber es ist ideal für das lokale Testen von APIs oder innerhalb von Docker-Containern, wo Entwickler experimentieren oder Unit-Tests gegen echte Endpunkte schreiben.

Integration der Konfiguration in Program.cs

Tim registriert die CORS-Dienste und wendet die Konfiguration in Program.cs an:

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

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

Diese Modularität verbessert die Codequalität und erleichtert das Hinzufügen von Mocking-Frameworks oder das Einfügen von Testverhaltensweisen in der Zukunft. Sie spiegelt wider, wie man Dinge für Unit-Tests in C# strukturieren würde, wo zentralisierte Konfigurationen die Testeinrichtung vereinfachen können.

Nachprüfung des Frontends

Nach der Anwendung der CORS-Korrektur führt Tim beide Anwendungen erneut aus. Diesmal funktioniert das Blazor-Frontend wie erwartet - die Kursdaten werden erfolgreich geladen, und jedes Kursbild verweist auf die entsprechende URL.

Wichtig ist, dass keine Änderungen am Frontend vorgenommen wurden. Die gesamte Korrektur erfolgte auf der API-Ebene durch eine ordnungsgemäße CORS-Konfiguration.

Lektionen in Test- und Einrichtungsstrategie

Obwohl Tim in diesem Video nicht direkt auf Unit-Testing-Frameworks eingeht, legt er mit seinem Ansatz den Grundstein dafür. Hier ist wie:

• Er sorgt für eine saubere Trennung der Bereiche und ermöglicht so die Verwendung von Testklassen und Mock-Objekten in der Zukunft.

• Die spezielle CORS-Einrichtungsdatei kann während der Tests wiederverwendet oder durch eine Scheinkonfiguration ersetzt werden.

• Sein schnelles Frontend-Projekt wirkt wie ein manueller Integrationstest - eine frühe Validierung vor dem Schreiben vollständiger Unit-Test-Projekte.

Dies spiegelt wider, wie Sie sich dem Testen in Visual Studio nähern würden:

• Erstellen Sie ein Unit-Test-Projekt neben Ihrer Hauptanwendung.

• Verwenden Sie Test Explorer, um alle Testmethoden auszuführen und die Ergebnisse zu verfolgen.

• Mocking externer Abhängigkeiten wie HTTP-Anfragen, Datenbankaufrufe oder Konfigurationsdateien.

• Schreiben Sie einfache Unit-Tests, um das erwartete Verhalten zu validieren, und erweitern Sie diese dann, um Testfälle mit Randbedingungen abzudecken.

Unit-Testing-Überlegungen für CORS-Szenarien

In Tims Video geht es zwar in erster Linie um die Konfiguration von CORS, aber die Auswirkungen auf das Testen von Software sind klar:

• Sie können Unit-Test-Methoden erstellen, um Ihre Konfigurationsdienste zu validieren.

• Simulieren Sie mithilfe von Mocking-Frameworks externe Faktoren wie unterschiedliche Ursprünge oder HTTP-Methoden.

• Führen Sie Testausführungen als Teil Ihres CI/CD-Prozesses durch, um zu bestätigen, dass Ihre Testmethoden durchgängig erfolgreich sind.

• Integrieren Sie Tests in den Visual Studio Test Explorer, um Fehler zu verfolgen und Stabilität zu gewährleisten.

Abschluss

In diesem Video-Tutorial bietet Tim Corey ein praktisches Beispiel für die Verwaltung von CORS in einer C#-Web-API und erstellt ein einfaches Blazor-Frontend, um die Konnektivität zu testen. Bei seinem Ansatz geht es nicht nur darum, einen Browserfehler zu beheben, sondern eine Struktur zu schaffen, die wartbaren Code, eine saubere Architektur und eine einfache Erweiterung in automatisierte Tests fördert.

Von hier aus können Entwickler selbstbewusst mit dem Schreiben von Unit-Tests, dem Einrichten von Integrationstests und der Verwendung von Tools wie Visual Studio, Test Explorer und Mocking-Frameworks zur Verbesserung der Codequalität und -zuverlässigkeit fortfahren.

Ganz gleich, ob Sie lernen, wie Sie mit dem Testen beginnen, Ihren ersten Unit-Test schreiben oder sicherstellen, dass Testmethoden erwartungsgemäß fehlschlagen - diese Lektion bietet die Grundlage für einen starken Entwicklungsprozess. Und das Wichtigste: Am Anfang stehen die richtige Architektur und Konfiguration.