Dodawanie spowolnień i kodów błędów — kurs tworzenia przykładowego interfejsu API w języku C#

Tim Corey

16m 21s

Podczas tworzenia i testowania nowoczesnych aplikacji, zwłaszcza tych z interfejsem webowym, programiści często muszą symulować scenariusze rzeczywiste, takie jak opoźnienia API i niespodziewane odpowiedzi błędów. Aby to umożliwić, Tim Corey przedstawia bardzo praktyczne przejście w lekcji swojego kursu zatytułowanej "Dodawanie opoźnień i kodów błędów - Budowanie przykładowego API w C#". W tym wideo Tim ilustruje, jak wzbogacić minimalistyczne API w C# o sztuczne opoźnienia i niestandardowe odpowiedzi błędów — bezcenne narzędzia do symulacji negatywnych sytuacji podczas testowania.

W tym artykułe przeprowadzimy cię przez koncepcje i implementacje, które Tim demonstruje na wideo.

Wprowadzenie do przykładowego API i jego celu

Tim rozpoczyna lekcję, podkreślając wartość posiadania przykładowego API podczas nauki tworzenia stron internetowych. Takie API daje ci coś konkretnego, aby testować swoje front-endowe aplikacje.

Do końca kursu Tim zamierza zbudować solidne API, które obejmuje:

• Przykładowe dane

• Dokumentację

• Sprawdzenia zdrowia

• Symulowane opoźnienia

• Symulowane błędy

• Opcje wdrożenia przez Docker i VPS

W tej konkretnej lekcji Tim koncentruje się na symulacji opoźnień i generowaniu kodów błędów dla realistycznego zachowania API w trudnych warunkach.

Dodawanie sztucznych opoźnień do punktów końcowych API

Tim zaczyna, dodając opcjonalny parametr opoźnienia do konkretnych punktów końcowych API — szczególnie tych dotyczących danych kursu. Jego celem jest symulowanie wolnych odpowiedzi API, aby lepiej testować front-end.

Szczegóły implementacji:

• Parametr opoźnienia jest mieleniem całkowitym reprezentującym milisekundy.

• Aby to obsłużyć, Tim przekształca metody punktu końcowego w metody asynchroniczne (async), które zwracają Task<IResult> zamiast jedynie IResult.

• Jeśli opoźnienie zostanie podane i mieści się w dopuszczalnych granicach (nie przekracza 300 000 milisekund lub 5 minut), metoda wywołuje Task.Delay(), aby wstrzymać wykonanie.

Na 2:33, Tim podkreśla znaczenie ograniczenia opoźnienia. Ustala limit na 5 minut, aby zapobiec nielogicznie długim czasom oczekiwania, które mogłyby sprawić, że aplikacja byłaby nieodpowiedzialna lub wyglądałaby na uszkodzoną.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

Ten dodatek zapewnia, że programiści mogą symulować opoźnienia do pięciu minut, co jest przydatne do testowania timeoutów i reaktywności w aplikacji klienta.

Testowanie mechanizmu opoźnienia

Tim wykonuje kilka testów za pomocą Postman (lub klona Postman), aby zweryfikować logikę opoźnienia. Na przykład:

• Opoźnienie=5000 (5 sekund) powoduje, że API się pauzuje przed zwróceniem wyników.

• Opoźnienie=500 efektywnie powoduje krótszą pauzę.

Obserwuje, że rzeczywiste opoźnienie będzie zawsze nieco dłuższe niż podana wartość z powodu obciążenia przetwarzania — ważna rzeczywista subtelność. Jak zauważa Tim na 5:09, nie mierzysz API co do milisekundy, ale raczej symulujesz prog.

Rozszerzanie funkcjonalności opoźnienia na więcej punktów końcowych

Tim nie zatrzymuje się tylko na punkcie końcowym "załaduj wszystkie kursy". Chce spójności, więc implementuje tę samą zdolność opoźnienia w punkcie końcowym "załaduj kurs przez ID".

Na 6:15, napotyka problem: konflikt nazw z powodu automatycznego dodania "Async" do nazwy metody podczas przekształcania na asynchroniczną. Tim dostosowuje obie nazwy metod, aby dostosować je do konwencji nazewniczej Async dla przejrzystości i spójności.

Testowanie potwierdza implementację:

• Opoźnienia są respektowane.

• Nieistniejące rekords zwracają 404 zgodnie z oczekiwaniami po opoźnieniu.

• Usunięcie opoźnienia lub przekazanie pustych wartości zachowuje się odpowiednio, Tim zauważa jednak pewną anomalię interfejsu użytkownika w Postman, a nie z API samym w sobie (8:00).

Dodawanie niestandardowych odpowiedzi błędów

Następnie Tim wprowadza wartościowe narzędzie do testowania API: dedykowany punkt końcowy, który może symulować różne kody błędów HTTP.

Na 9:13, wyjaśnia, że choć niektóre punkty końcowe (jak ten, który zwraca kurs przez ID) naturalnie zwracają 404 dla brakujących danych, nie ma wbudowanego sposobu na testowanie innych kodów błędów — chyba że są one wyraźnie symulowane.

Tim buduje nowy punkt końcowy przy /error/{code}, który:

• Akceptuje całkowity kod statusu HTTP.

• Zwraca odpowiadającą odpowiedź błędu HTTP za pomocą wyrażenia switch.

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Obejmuje to zarówno typowe błędy po stronie klienta, jak i dowolne zdefiniowane przez siebie kody, które deweloper może chcieć przetestować.

Na 12:03, dodaje ten nowy punkt końcowy do programu przez app.AddErrorEndpoints() i oznacza klasę błędu jako statyczną.

Testowanie punktu końcowego błędów

Tim teraz testuje punkt końcowy, przekazując różne kody statusu:

• 400 zwraca "Złe żądanie"

• 401 zwraca "Nieautoryzowany"

• 404 zwraca "Nie znaleziono"

• 301 zwraca "Trwale przeniesiony"

• 405 zwraca "Metoda niedozwolona"

Pokazuje to elastyczność punktu końcowego — nie tylko dla kodów błędów, ale dla dowolnego kodu statusu HTTP. Na 13:04, Tim potwierdza, że to podejście jest idealne do testowania, jak front-endowe aplikacje obsługują różne odpowiedzi serwera.

Rozważał nazwanie go /httpcode, ale utrzymał /error dla prostoty, jako że jest on przede wszystkim używany do symulacji warunków błędów.

Podsumowanie ulepszeń funkcjonalnych

Tim kończy wideo, podsumowując ulepszenia wprowadzone do API:

• Opoźnienia symulują rzeczywiste opoźnienia w odpowiedziach API.

• Symulacja błędów zapewnia elastyczność testowania praktycznie każdej odpowiedzi HTTP.

• Te funkcje sprawiają, że przykładowe API jest bardziej solidne i wartościowe dla realistycznych scenariuszy testowania.

Na 14:16, Tim podkreśla znaczenie tych narzędzi do testowania, jak aplikacja zachowuje się w różnych stanach API, takich jak opoźnione odpowiedzi czy różne błędy serwera.

Co dalej: Dockerization API

Chociaż nie opisano tego szczegółowo w tym wideo, Tim sugeruje kolejny krok: Dockerization API. To pozwala programistom uruchamiać przykładowe API lokalnie w samodzielnym kontenerze Docker, co ułatwia wdrażanie i udostępnianie w różnych środowiskach.

Podsumowanie

Tim kończy wideo, ponownie podkreślając swoje zaangażowanie w tworzenie kompleksowego przykładowego API, które obejmuje realistyczne funkcje, których programiści naprawdę potrzebują do testowania. Obejmują one:

• Opoźnienia

• Błędy

• Sprawdzenia zdrowia

• Plany na przyszłość dotyczące uwierzytelniania i zaawansowanych punktów końcowych

Cel jest prosty, ale potężny — wyposażenie deweloperów w narzędzie, które naśladuje kaprysy prawdziwych API, dzięki czemu ich aplikacje są solidne, niezawodne i przyjazne dla użytkownika.

Wnioski

Do końca tej lekcji widzowie zyskują lepsze zrozumienie, jak i dlaczego wprowadzać sztuczne opoźnienia i odpowiedzi błędów w swoich API. Podejście Tima Corey'a jest metodyczne, praktyczne i bezpośrednio związane z potrzebami testowania rzeczywistych aplikacji. Jeśli szukasz sposobu, aby wzmocnić swoje testy API, ta lekcja jest doskonałym zasobem do naśladowania — a teraz dokładnie wiesz, gdzie szukać.

Obejrzyj pełną lekcję wideo Tima Corey, aby uzyskać praktyczne wskazówki.