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

Tim Corey

23m 30s

Opracowywanie i testowanie RESTful API w C# z użyciem ASP.NET Core to praktyczna umiejętność dla każdego nowoczesnego dewelopera backendu. W swoim filmie instruktażowym na temat "Dodawanie sprawdzeń zdrowia - Budowanie przykładowego API w kursie C#", Tim Corey prowadzi podczas budowania przykładowego API z zintegrowanymi sprawdzeniami zdrowia. Ten artykuł, oparty wyłącznie na transkrypcji Tima, tłumaczy cały proces krok po kroku, obejmując kluczowe punkty, takie jak użycie public async Task, int id, var app oraz inne metody żądań HTTP.

Przyjrzyjmy się dokładniej, jak Tim Corey konfiguruje sprawdzenia zdrowia w projekcie API w C# przy użyciu Visual Studio Code.

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.

HealthyHealthCheck.cs

Ta klasa zwraca HealthCheckResult.Healthy używając implementacji public async Task<HealthCheckResult>:

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.Healthy("This is a test healthy service."))

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

Symuluje to zdrowy status, przydatne do testowania, jak frontend radzi sobie z stabilną usługą.

DegradedHealthCheck.cs

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.Degraded("This is a test degraded service."))

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

To sprawdzenie zwraca odpowiedź o pogorszonej usłudze. To prosty sposób na symulowanie częściowej awarii lub problemów z wydajnością.

UnhealthyHealthCheck.cs

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

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

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

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

Imituje to awarię usługi, symulując przypadki, w których można by oczekiwać kodu statusu HTTP 500 lub zwrócić NotFound().

RandomHealthCheck.cs

To sprawdzenie zdrowia korzysta z losowej liczby całkowitej, aby symulować jeden z trzech stanów:

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."))
};

Dim randomResult As Integer = Random.Shared.Next(1, 4)
Return randomResult Select Case
    Case 1
        Task.FromResult(HealthCheckResult.Healthy("This is a test random service."))
    Case 2
        Task.FromResult(HealthCheckResult.Degraded("This is a test random service."))
    Case 3
        Task.FromResult(HealthCheckResult.Unhealthy("This is a test random service."))
    Case Else
        Task.FromResult(HealthCheckResult.Healthy("This is a test random service."))
End Select

Dim randomResult As Integer = Random.Shared.Next(1, 4)
Return randomResult Select Case
    Case 1
        Task.FromResult(HealthCheckResult.Healthy("This is a test random service."))
    Case 2
        Task.FromResult(HealthCheckResult.Degraded("This is a test random service."))
    Case 3
        Task.FromResult(HealthCheckResult.Unhealthy("This is a test random service."))
    Case Else
        Task.FromResult(HealthCheckResult.Healthy("This is a test random service."))
End Select

Tim podkreśla, że jest to przydatne do testowania zachowania w zmiennych warunkach.

Rejestracja sprawdzeń zdrowia w konfiguracji Startowej

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

AddAllHealthChecks()

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" });

services.AddHealthChecks() _
    .AddCheck(Of RandomHealthCheck)("random", tags:=New String() {"random"}) _
    .AddCheck(Of HealthyHealthCheck)("healthy", tags:=New String() {"healthy"}) _
    .AddCheck(Of DegradedHealthCheck)("degraded", tags:=New String() {"degraded"}) _
    .AddCheck(Of UnhealthyHealthCheck)("unhealthy", tags:=New String() {"unhealthy"})

services.AddHealthChecks() _
    .AddCheck(Of RandomHealthCheck)("random", tags:=New String() {"random"}) _
    .AddCheck(Of HealthyHealthCheck)("healthy", tags:=New String() {"healthy"}) _
    .AddCheck(Of DegradedHealthCheck)("degraded", tags:=New String() {"degraded"}) _
    .AddCheck(Of UnhealthyHealthCheck)("unhealthy", tags:=New String() {"unhealthy"})

Rejestruje to wszystkie sprawdzenia zdrowia do wstrzykiwania zależności w kontenerze usług ASP.NET Core.

MapAllHealthChecks()

app.MapHealthChecks("/health");

app.MapHealthChecks("/health");

app.MapHealthChecks("/health")

app.MapHealthChecks("/health")

Tworzy to jeden punkt końcowy /health, który ocenia wszystkie usługi razem. Jeśli jakakolwiek z nich jest niezdrowa, całe sprawdzenie zwraca niezdrowe.

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")
});

app.MapHealthChecks("/health/healthy", New HealthCheckOptions With {
    .Predicate = Function(x) x.Tags.Contains("healthy")
})

app.MapHealthChecks("/health/healthy", New HealthCheckOptions With {
    .Predicate = Function(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
});

app.MapHealthChecks("/healthui", New HealthCheckOptions With {
    .ResponseWriter = AddressOf UIResponseWriter.WriteHealthCheckUIResponse
})

app.MapHealthChecks("/healthui", New HealthCheckOptions With {
    .ResponseWriter = AddressOf 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/zdrowy

• /healthui/zdegenerowany

• /healthui/niezdrowy

• /healthui/losowy

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.