Zarządzanie CORS i testowanie — kurs tworzenia przykładowego interfejsu API w języku C#

Ustawianie frontendu Blazor

Tim rozpoczyna lekcję od utworzenia prostego projektu frontendowego Blazor WebAssembly o nazwie SampleTestUI. Ten frontend nie jest gotowy do produkcji—jest to raczej projekt testowy do zweryfikowania łączności z API i celowego wywołania problemu z CORS.

• Tim używa szablonu .NET 9 i rezygnuje z funkcji uwierzytelniania czy PWA.

• Celem frontendu jest symulacja rzeczywistych wywołań API i odkrycie błędów testowych związanych z żądaniami cross-origin.

• Modyfikuje stronę główną, aby wywołać punkt końcowy API /courses i wyświetlić listę kursów z powiązanymi obrazami.

Frontend używa prostej klasy modelu (CourseModel) utworzonej oddzielnie, zamiast dzielenia modelu z API. Tim podkreśla, że modele frontendowe powinny być oddzielone od modeli dostępu do danych, aby zmniejszyć sprzężenie i zwiększyć łatwość konserwacji (2:28). To ważna zasada przy pisaniu testów utrzymywalnych i testowalnego kodu.

Pisanie wywołania API

Aby pobrać dane z API:

• Tim wstrzykuje HttpClienta.

• Pisze asynchroniczną metodę używając Http.GetFromJsonAsync<List>().

• Metoda jest zakodowana na sztywno z lokalnym URL-em API (4:00), służąc jako prosty test do walidacji komunikacji między frontendem a backendem.

Nie ma tu metody testowej ani obsługi błędów, tylko prosty wywołanie. To ustawienie odzwierciedla wczesne kroki w pisaniu testów jednostkowych, gdzie zaczynasz od walidacji podstawowej interakcji między komponentami.

Budowanie logiki pobierania danych i interfejsu użytkownika

Po zakodowaniu na sztywno URL-u API o 4:00, Tim koncentruje się na budowie głównej logiki pobierania danych kursów z API i ich wyświetlania w frontendzie Blazor. To kluczowy krok w walidacji, że frontend może współdziałać z backendem, nawet przed napisaniem testów automatycznych czy użyciem frameworka testowego.

Najpierw upewnia się, że używany jest prawidłowy URL z launchSettings.json API—pobierając adres HTTPS i dodając /courses, aby utworzyć pełny punkt końcowy. To ważne, ponieważ przeglądarki często odrzucają żądania API nie-HTTPS z zabezpieczonych stron.

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

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

Wyświetlanie danych

Gdy dane są pobierane, Tim pisze prostą pętlę UI używając składni Razor, aby iterować po liście kursów:

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

Każdy kurs jest pokazywany jako obraz w obramowaniu hiperłącza. Tim zauważa, że obrazy są duże (1920x1080), więc ogranicza szerokość do 300px, aby nie przytłaczać strony.

To wyjście działa jako wizualne potwierdzenie, że dane API przepływają poprawnie do frontendu. Symuluje to rodzaj opinii, jaką chcesz uzyskać z testu—jeżeli obrazy się pojawiają, żądanie się powiodło.

Przygotowanie do uruchomienia

Przed uruchomieniem aplikacji Tim konfiguruje wiele projektów startowych w Visual Studio. Ustawia projekt API jako pierwszy, a następnie frontend Blazor. Kolejność ta jest kluczowa, aby zapewnić gotowość API w momencie, gdy frontend próbuje pobrać dane.

Ten końcowy krok o 6:30 przygotowuje grunt do uruchomienia testu — i napotkania błędu CORS — od którego rozpoczyna się kolejna część samouczka.

Napotykanie na mur CORS

Gdy Tim uruchamia oba projekty jednocześnie korzystając z eksploratora rozwiązań Visual Studio, frontend próbuje wywołać API—ale nie udaje się. Konsola przeglądarki wyświetla znajomą wiadomość:

"Dostęp do fetch przy 'API URL' z pochodzenia 'Frontend URL' został zablokowany przez zasadę CORS..."(7:02)

To jest moment, w którym rozumienie i zarządzanie CORS staje się niezbędne. Bez odpowiednich nagłówków, przeglądarka blokuje żądania z jednego pochodzenia do innego.

Tworzenie klasy konfiguracji CORS

Zamiast zaśmiećać Program.cs, Tim tworzy dedykowaną klasę o nazwie CorsConfig w folderze Startup. Używa struktury klasy statycznej, aby zastosować ten sam wzór konfiguracji, który jest używany do ustawień Swagger i OpenAPI.

Zgadza się to z praktykami czystego kodu i sprawia, że aplikacja jest bardziej testowalna. Modularne konfiguracje jak ta również ułatwiają pisanie metod testowych później, ponieważ logika jest izolowana i łatwiejsza do mockowania lub nadpisywania.

Stosowanie liberalnej polityki CORS

Tim definiuje bardzo otwartą politykę CORS, aby pozwolić na pełny dostęp cross-origin:

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

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

To ustawienie jest przydatne w rozwoju opartym na testach i testach integracyjnych, gdzie zewnętrzne usługi lub aplikacje frontendowe potrzebują pełnego dostępu do API. Tim nazywaą tę politykę "AllowAll" i zapisuje nazwę w stałej, aby zapobiec literówkom i niespójnościom (11:00):

private const string AllowAllPolicy = "AllowAll";

private const string AllowAllPolicy = "AllowAll";

Zwraca uwagę, że nie powinno to być używane w produkcji, ale jest idealne do testowania API lokalnie lub w środowiskach Docker, gdzie deweloperzy eksperymentują lub piszą testy jednostkowe przeciwko rzeczywistym punktom końcowym.

Integracja konfiguracji w Program.cs

Tim rejestruje usługi CORS i stosuje konfigurację w Program.cs:

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

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

Ta modularność poprawia jakość kodu, i ułatwia dodanie frameworków mockowania lub wprowadzenie zachowań testowych w przyszłości. Odzwierciedla to sposób, w jaki organizowałbyś rzeczy dla testów jednostkowych w C#, gdzie posiadanie scentralizowanych konfiguracji może uprościć konfigurację testów.

Ponowne testowanie frontendu

Po zastosowaniu rozwiązania CORS, Tim ponownie uruchamia obie aplikacje. Tym razem frontend Blazor działa zgodnie z oczekiwaniami—dane kursu ładują się pomyślnie, a każdy obrazek kursu łączy się z odpowiednim URL-em.

Co ważne, nie dokonano żadnych zmian w frontendzie. Całe rozwiązanie miało miejsce na poziomie API, poprzez odpowiednią konfigurację CORS.

Lekcje o strategii testowania i konfiguracji

Chociaż Tim nie zagłębia się bezpośrednio w frameworki testów jednostkowych w tym filmie, jego podejście stanowi grunt do tego. Oto jak:

• Oddziela on odpowiedziąlności w sposób czysty, umożliwiający użycie klas testowych i obiektów mock w przyszłości.

• Dedykowany plik konfiguracji CORS można ponownie użyć lub zastąpić konfiguracją mock podczas testów.

• Jego szybki projekt frontendu działa jak ręczny test integracyjny—wczesna walidacja przed pisaniem pełnych projektów testów jednostkowych.

To odzwierciedla sposób, w jaki podchodzisz do testowania w Visual Studio:

• Utwórz projekt testowy jednostkowy obok swojej głównej aplikacji.

• Użyj Test Explorera, aby uruchomić wszystkie metody testowe i śledzić wyniki.

• Mockuj zewnętrzne zależności, takie jak żądania HTTP, wywołania do bazy danych, czy pliki konfiguracyjne.

• Napisz proste testy jednostkowe, aby zweryfikować spodziewane zachowanie, a następnie rozszerz je, aby objąć przypadki testowe z warunkami granicznymi.

Rozważania dotyczące testów jednostkowych w scenariuszach CORS

Chociaż wideo Tima dotyczy przede wszystkim konfiguracji CORS, implikacje dla testowania oprogramowania są jasne:

• Możesz stworzyć metody testowe jednostkowe, które walidują twoje usługi konfiguracji.

• Używając frameworków mockowania, symuluj zewnętrzne czynniki, takie jak różne pochodzenia czy metody HTTP.

• Uruchamiaj testy jako część swojego procesu CI/CD, aby potwierdzić, że twoje metody testowe przechodzą konsekwentnie.

• Włącz testy do Visual Studio Test Explorer, aby śledzić awarie i zapewnić stabilność.

Wnioski

W tym tutorialu wideo Tim Corey oferuje praktyczny przykład zarządzania CORS w Web API C#, podczas budowania prostego frontendu Blazor do testowania łączności. Jego podejście nie polega tylko na naprawie błędu przeglądarki—ustawia ono strukturę, która zachęca do utrzymywalnego kodu, czystej architektury oraz łatwego rozszerzania na testowanie automatyczne.

Od tego miejsca programiści mogą pewnie przejść do pisania testów jednostkowych, ustawiania testów integracyjnych i używania narzędzi takich jak Visual Studio, Test Explorer i frameworki mockowania do poprawy jakości kodu i niezawodności.

Bez względu na to, czy uczysz się rozpocząć testowanie, napisać swój pierwszy test jednostkowy, czy zapewnić, że metody testowe zawodzą, kiedy się tego spodziewasz, ta lekcja daje podstawy dla silnego procesu rozwoju. A co najważniejsze—wszystko zaczyna się od uzyskania właściwej architektury i konfiguracji.