Hinzufügen von Verlangsamungen und Fehlercodes - Erstellen einer Beispiel-API in C# Kurs

Einführung in die Beispiel-API und ihr Zweck

Tim beginnt die Lektion, indem er den Wert einer Beispiel-API beim Erlernen der Web-Entwicklung wiederholt. Eine solche API gibt Ihnen etwas Konkretes, an dem Sie Ihre Front-End-Anwendungen testen können.

Am Ende des Kurses möchte Tim eine robuste API erstellen, die Folgendes umfasst:

• Beispieldaten

• Dokumentation

• Gesundheitschecks

• Simulierte Verlangsamungen

• Simulierte Fehler

• Bereitstellungsoptionen über Docker und VPS

In dieser speziellen Lektion konzentriert sich Tim auf die Simulation von Verlangsamungen und die Erzeugung von Fehlercodes für ein realistisches API-Verhalten unter ungünstigen Bedingungen.

Zufügen von künstlichen Verzögerungen zu API-Endpunkten

Tim beginnt mit dem Hinzufügen eines optionalen Verzögerungsparameters zu bestimmten API-Endpunkten - insbesondere solchen, die mit Kursdaten zu tun haben. Sein Ziel ist es, langsame API-Antworten für bessere Front-End-Tests zu simulieren.

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

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

Test des Verzögerungsmechanismus

Tim führt ein paar Tests mit Postman (oder einem Postman-Klon) durch, um die Verzögerungslogik zu überprüfen. Zum Beispiel:

• Ein delay=5000 (5 Sekunden) bewirkt, dass die API eine Pause einlegt, bevor sie Ergebnisse zurückgibt.

• Ein delay=500 führt zu einer kürzeren Pause.

Er merkt an, dass die tatsächliche Verzögerung aufgrund des Verarbeitungsaufwands immer etwas länger sein wird als der angegebene Wert - eine wichtige Nuance in der Praxis. Wie Tim bei 5:09 anmerkt, geht es nicht darum, die API auf die Millisekunde genau zu timen, sondern eher darum, einen Schwellenwert zu simulieren.

Erweiterung der Verzögerungsfunktionalität auf mehr Endpunkte

Tim beschränkt sich nicht nur auf den Endpunkt "Alle Kurse laden". Er möchte Konsistenz, daher implementiert er die gleiche Verzögerungsfunktion im Endpunkt "Kurs nach ID laden".

Bei 6:15 stößt er auf ein Problem: einen Namenskonflikt aufgrund der automatischen Hinzufügung von "Async" zum Methodennamen bei der Konvertierung in asynchron. Tim passt beide Methodennamen an die Async-Benennungskonvention an, um Klarheit und Konsistenz zu gewährleisten.

Der Test bestätigt die Umsetzung:

• Fristen werden respektiert.

• Nicht vorhandene Datensätze geben nach der Verzögerung wie erwartet 404 zurück.

• Das Entfernen der Verzögerung oder die Übergabe leerer Werte verhält sich angemessen, wobei Tim eher auf eine Eigenart der Benutzeroberfläche von Postman als auf ein Problem mit der API selbst hinweist (8:00).

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

Testen des Fehler-Endpunkts

Tim testet nun den Fehlerendpunkt, indem er verschiedene Statuscodes übergibt:

• 400 gibt "Schlechte Anfrage" zurück

• 401 gibt "Unautorisiert" zurück

• 404 gibt "Nicht gefunden" zurück

• 301 gibt "Dauerhaft verschoben" zurück

• 405 gibt "Methode nicht erlaubt" zurück

Dies zeigt die Flexibilität des Endpunkts - nicht nur für Fehlercodes, sondern für jeden HTTP-Statuscode. Bei 13:04 bestätigt Tim, dass dieser Ansatz ideal ist, um zu testen, wie Front-End-Anwendungen mit verschiedenen Serverantworten umgehen.

Obwohl er den Namen /httpcode in Erwägung zog, entschied er sich der Einfachheit halber für /error, da es in erster Linie zur Simulation von Fehlerbedingungen verwendet wird.

Zusammenfassung der Funktionserweiterungen

Zum Abschluss des Videos fasst Tim die Verbesserungen an der API zusammen:

• Slowdowns simulieren reale Latenzzeiten bei API-Antworten.

• die Fehlersimulation bietet die Flexibilität, gegen praktisch jede HTTP-Antwort zu testen.

• Diese Funktionen machen die Beispiel-API robuster und sind für realistische Testszenarien von unschätzbarem Wert.

Bei 14:16 betont Tim, wie wichtig diese Tools sind, um zu testen, wie sich Ihre Anwendung bei verschiedenen API-Zuständen verhält, z. B. bei verzögerten Antworten oder verschiedenen Serverfehlern.

Was kommt als nächstes? Dockerisierung der API

Obwohl in diesem Video nicht im Detail behandelt, weist Tim auf den nächsten Schritt hin: Die Dockerisierung der API. So können Entwickler die Beispiel-API lokal in einem in sich geschlossenen Docker-Container ausführen, was die Bereitstellung und gemeinsame Nutzung in verschiedenen Umgebungen erleichtert.

Abschließende Gedanken

Tim schließt das Video, indem er sein Engagement für den Aufbau einer umfassenden Beispiel-API bekräftigt, die realistische Funktionen enthält, die Entwickler tatsächlich benötigen, um sie zu testen. Dazu gehören:

• Verzögerungen

• Fehler

• Gesundheitschecks

• Zukunftspläne für Authentifizierung und fortgeschrittene Endpunkte

Das Ziel ist einfach, aber wirkungsvoll: Entwicklern ein Werkzeug an die Hand zu geben, das die Eigenheiten echter APIs nachahmt, damit ihre Anwendungen robust, zuverlässig und benutzerfreundlich sind.

Abschluss

Am Ende dieser Lektion haben die Zuschauer ein besseres Verständnis dafür, wie und warum sie künstliche Verzögerungen und Fehlerreaktionen in ihre APIs einbauen können. Der Ansatz von Tim Corey ist methodisch, praktisch und direkt auf die Anforderungen beim Testen von Anwendungen bezogen. Wenn Sie Ihre API-Tests verbessern möchten, ist diese Lektion eine hervorragende Ressource, die Sie befolgen sollten - und jetzt wissen Sie genau, wo Sie suchen müssen.

Sehen Sie sich die vollständige Video-Lektion von Tim Corey an, um eine praktische Anleitung zu erhalten.