Dodawanie testów sprawdzających działanie — kurs tworzenia przykładowego interfejsu API w języku C#

Wprowadzenie do przykładowego API i sprawdzeń zdrowia

Tim wyjaśnia, że przykładowe API jest potężnym narzędziem przy nauce tworzenia aplikacji internetowych. Pozwala deweloperom na symulowanie wywołań API za pomocą metod GET, POST, PUT i DELETE, z odpowiednimi danymi żądania i kodami statusu. API zbudowane przez Tima obsługuje:

• Przykładowe dane z modelem danych

• Zachowania RESTful dla żądań API

• Odpowiedzi w formacie JSON

• Sprawdzenia zdrowia

• Wdrożenie zarówno jako kontenery Docker, jak i aplikacje internetowe

Instalacja pakietu Health Checks

Tim otwiera projekt w Visual Studio Code i klikając prawym przyciskiem myszy na Zależności, zarządza pakietami NuGet. Wyszukuje i instaluje pakiet AspNetCore.HealthChecks.UI.Client. Pozwala to aplikacji obsługiwać dwa typy sprawdzeń zdrowia.

Tworzenie klas sprawdzeń zdrowia

Tim dodaje nowy folder o nazwie HealthChecks w folderze projektu API. Tutaj tworzy wiele klas implementujących interfejs IHealthCheck, z których każda reprezentuje inny status: zdrowy, pogorszony, niezdrowy i losowy.

return Task.FromResult(HealthCheckResult.Healthy("This is a test healthy service."));

return Task.FromResult(HealthCheckResult.Healthy("This is a test healthy service."));

return Task.FromResult(HealthCheckResult.Degraded("This is a test degraded service."));

return Task.FromResult(HealthCheckResult.Degraded("This is a test degraded service."));

return Task.FromResult(HealthCheckResult.Unhealthy("This is a test unhealthy service."));

return Task.FromResult(HealthCheckResult.Unhealthy("This is a test unhealthy service."));

int randomResult = Random.Shared.Next(1, 4);
return randomResult switch
{
    1 => Task.FromResult(HealthCheckResult.Healthy("This is a test random service.")),
    2 => Task.FromResult(HealthCheckResult.Degraded("This is a test random service.")),
    3 => Task.FromResult(HealthCheckResult.Unhealthy("This is a test random service.")),
    _ => Task.FromResult(HealthCheckResult.Healthy("This is a test random service."))
};

int randomResult = Random.Shared.Next(1, 4);
return randomResult switch
{
    1 => Task.FromResult(HealthCheckResult.Healthy("This is a test random service.")),
    2 => Task.FromResult(HealthCheckResult.Degraded("This is a test random service.")),
    3 => Task.FromResult(HealthCheckResult.Unhealthy("This is a test random service.")),
    _ => Task.FromResult(HealthCheckResult.Healthy("This is a test random service."))
};

Rejestracja sprawdzeń zdrowia w konfiguracji Startowej

Tim dodaje nową statyczną klasę HealthChecksConfig.cs w folderze startowym lub konfiguracyjnym. Ta klasa zawiera dwie metody statyczne:

services.AddHealthChecks()
    .AddCheck<RandomHealthCheck>("random", tags: new[] { "random" })
    .AddCheck<HealthyHealthCheck>("healthy", tags: new[] { "healthy" })
    .AddCheck<DegradedHealthCheck>("degraded", tags: new[] { "degraded" })
    .AddCheck<UnhealthyHealthCheck>("unhealthy", tags: new[] { "unhealthy" });

services.AddHealthChecks()
    .AddCheck<RandomHealthCheck>("random", tags: new[] { "random" })
    .AddCheck<HealthyHealthCheck>("healthy", tags: new[] { "healthy" })
    .AddCheck<DegradedHealthCheck>("degraded", tags: new[] { "degraded" })
    .AddCheck<UnhealthyHealthCheck>("unhealthy", tags: new[] { "unhealthy" });

app.MapHealthChecks("/health");

app.MapHealthChecks("/health");

Tworzenie specyficznych punktów końcowych zdrowia

Aby przetestować poszczególne komponenty, Tim mapuje każdy test zdrowia za pomocą tagu:

app.MapHealthChecks("/health/healthy", new HealthCheckOptions {
    Predicate = x => x.Tags.Contains("healthy")
});

app.MapHealthChecks("/health/healthy", new HealthCheckOptions {
    Predicate = x => x.Tags.Contains("healthy")
});

Powtarza to dla /health/degraded, /health/unhealthy i /health/random. Każdy pozwala deweloperom testować specyficzne zachowania i jak ich frontend na nie reaguje.

Podczas odwiedzania /health/random, wynik zmienia się między "zdrowy", "pogorszony" i "niezdrowy" w zależności od losowego wyniku.

Dodawanie wsparcia UI dla sprawdzeń zdrowia

Tim ulepsza punkty końcowe, umożliwiając odpowiedź UI dla każdej trasy sprawdzeń zdrowia. Zapewnia to wyjście JSON:

app.MapHealthChecks("/healthui", new HealthCheckOptions
{
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});

app.MapHealthChecks("/healthui", new HealthCheckOptions
{
    ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});

Umożliwia to inspekcję każdego sprawdzenia zdrowia z danymi takimi jak czas trwania, tagi i status. Tim następnie tworzy wersje UI dla każdego punktu końcowego zdrowia:

• /healthui/healthy

• /healthui/degraded

• /healthui/unhealthy

• /healthui/random

Każde odpowiada szczegółowym formatem JSON, idealnym dla RESTful API i testowania z urządzeń mobilnych lub stron internetowych.

Podsumowanie projektu API

Tim podkreśla, że nawet z tymi funkcjami, Program.cs ma tylko 21 linii. Przypisuje to do:

• Dobra struktura folderów projektowych

• Trzymywanie modeli w folderze Models

• Umieszczanie punktów końcowych i kontrolerów w ich własnych folderach

• Używanie metod async Task dla każdej klasy sprawdzeń zdrowia

Podkreśla również, jak użyteczne jest to przykładowe API w środowiskach produkcyjnych do symulowania opóźnień lub awarii przed wdrożeniem.

"Możemy przeprowadzić znacznie więcej testów z tym API poza tylko wykonywaniem wywołań GET", kończy Tim.

Co dalej

Tim zapowiada następną lekcję, gdzie doda symulowane spowolnienia (np. 5-sekundowe opóźnienia) i błędy, takie jak return NotFound() lub return BadRequest(), aby jeszcze bardziej przetestować zachowanie API.

Wnioski

W tym filmie instruktażowym, Tim Corey metodycznie przechodzi przez budowę minimalnego API z zintegrowanymi sprawdzeniami zdrowia przy użyciu ASP.NET Core. Kluczowe komponenty obejmują:

• Klasy sprawdzeń zdrowia (Healthy, Degraded, Unhealthy, Random)

• Wstrzykiwanie zależności za pomocą AddHealthChecks()

• Mapowanie punktów końcowych za pomocą MapHealthChecks()

• Wspieranie ustrukturyzowanych odpowiedzi JSON

To podejście ułatwia walidację REST APIs, symulację awarii i wzmacnianie aplikacji internetowych zarówno na etapie opracowywania, jak i produkcji.