Die App im selben Prozess testen

Deine App hat zwei Path Operations und noch keinen Weg, eine Anfrage zu empfangen. In Lektion 10.4 hast du einem httpx-Client einen eigenen Transport gegeben, httpx.MockTransport, dessen Handler jede Anfrage im selben Prozess beantwortet hat, ohne Server und ohne Port. FastAPI liefert dieselbe Idee mit, auf eine App gerichtet. Öffne tests/test_app.py; sein erster Test benutzt sie schon:

def fresh_client(state=None):
    reading_app.reset_state(state)
    return TestClient(reading_app.app)


def test_list_books_is_json():
    response = fresh_client().get("/books")
    assert response.status_code == 200
    assert response.json()["books"][0]["title"] == "Kindred"

TestClient(app) ist ein httpx-Client, dessen Transport die App direkt aufruft. get("/books") baut eine httpx.Request, der Transport übergibt sie FastAPI, als wäre sie über eine Verbindung angekommen, und die Antwort von FastAPI kommt als httpx.Response zurück, mit status_code, headers und json(), die du in Kapitel 10 benutzt hast. Die Basis-URL des Clients ist http://testserver, ein Name, den niemand nachschlägt: Es wird keine Verbindung aufgebaut, kein Port geöffnet, und nichts verlässt den Python-Prozess. Deshalb kann dieses Kapitel die App ohne Server testen.

Die Fälle aus Kapitel 5, noch einmal gestellt

Hier sind die Fälle für Lesezugriffe aus den Kapiteln 4 bis 6, gestellt an deinen Server aus Kapitel 9 in reading_server.py und an die FastAPI-App mit den Funktionen aus Lektion 1, mit den Versionen, die dieser Kurs benutzt (denen in requirements.txt):

Die ersten vier Zeilen antworten wie zuvor, mit einem Bruchteil des Codes. Die letzten vier sind Entscheidungen, die FastAPI für dich getroffen hat:

• HEAD. Die @app.get-Zeile registriert eine Route nur für GET, und FastAPI fügt ihr kein HEAD hinzu, also antwortet die App mit 405. In Lektion 4.5 hast du deinen eigenen Server HEAD wie GET beantworten lassen.

• Die allow-Liste. Zwei Routen teilen sich den Pfad /books, eine für GET und eine für POST. Wenn keine von beiden die Methode akzeptiert, nennt die 405 von FastAPI nur die Methoden der ersten Route, deren Pfad gepasst hat. RFC 9110 sagt, dass Allow die Methoden auflistet, die die Ressource unterstützt, also lässt diese Liste POST aus.

• /books/abc. Die Annotation book_id: int aus Lektion 1: FastAPI kann aus abc keinen int machen, also antwortet es mit 422, bevor deine Funktion läuft.

• Der Schrägstrich am Ende. FastAPI leitet /books/ mit einer 307 auf /books weiter, auf eine absolute URL, die aus dem Host gebaut wird, den die Anfrage genannt hat. Eine 307 behält die Methode bei, wie eine 308, sagt aber, dass der Umzug vorübergehend ist. TestClient folgt Weiterleitungen, außer du übergibst follow_redirects=False, also zeigt dir ein einfaches get("/books/") die 200 am Ende.

Die Tabelle teilt sich also an einer Linie. Finde heraus, wo jede Anfrage auf ihrem Weg hinein stehen bleibt:

GET /nowhere, HEAD /books, DELETE /books, GET /books/abc und GET /books/ erreichen deinen Code nie: FastAPI beantwortet sie selbst. Nur GET /books, GET /books/2 und GET /books/99 rufen deine Funktionen auf.

Tests, die eine Entscheidung festhalten

Die Zeilen für /books, /books/2 und /books/99 testen deine Funktionen. Die anderen testen FastAPI: Sogar die 404 für /nowhere stammt von FastAPI, da keine Route passt. Ein Test, der zusichert, dass HEAD /books eine 405 bekommt, behauptet nicht, dass 405 richtig ist. Er hält fest, was diese App heute tut, mit diesen Versionen. Wenn ein späteres FastAPI anfängt, HEAD zu beantworten, schlägt dieser Test fehl, und der Fehlschlag sagt dir, dass sich das Framework unter dir geändert hat. Das solltest du wissen, bevor ein Client es merkt. Der zweite Test aus Lektion 2 hält zwei dieser Antworten fest.

Den Client in jedem Test bauen

fresh_client() setzt STATE zurück und baut jedes Mal, wenn ein Test es aufruft, einen TestClient für reading_app.app. Das ist wichtig für Check my work: Es führt deine Tests gegen andere Versionen der App aus, jede mit einem Fehler, und setzt jede Version ein, indem es reading_app.app ersetzt. reading_app.get_book zu ersetzen würde nichts ändern, weil die Route die Funktion behält, die sie bekommen hat, als die @app.get-Zeile lief. Ein Test, der fresh_client() aufruft, schlägt reading_app.app nach, wenn er läuft, und trifft so auf die Version, die gerade eingesetzt ist. Ein Client, der einmal oben in der Datei gebaut wird, etwa client = TestClient(reading_app.app), behält die ursprüngliche App, und from reading_app import app ebenso.

Eine Warnung

Führe die Tests im Tab Shell aus:

python -m pytest -q

Die Zusammenfassungszeile endet mit 1 warning, und die Zusammenfassung der Warnungen darüber hat einen Eintrag, dessen letzte Zeile so endet:

DeprecationWarning: The anyio.abc.BlockingPortal alias is deprecated, use anyio.from_thread.BlockingPortal instead.

Sie stammt von anyio, der Bibliothek, mit der Starlette, das Toolkit, auf dem FastAPI aufbaut, den asynchronen Code der App ausführt. Der Hinweis betrifft einen Namen, den Starlette intern benutzt. Er kommt vom Import des Test-Clients und ändert kein Ergebnis.

Deine Aufgabe

Ersetze die beiden Platzhalter von Lektion 2 in tests/test_app.py, wobei jeder seinen Client mit fresh_client() baut:

1. test_unknown_book_is_404: GET /books/99 antwortet mit 404. Der Beispielzustand hat nur die Bücher 1 und 2.

2. test_choices_fastapi_makes: HEAD /books antwortet mit 405, und GET /books/abc antwortet mit 422.

Sichere Statuscodes zu; du kannst auch allow oder dein detail prüfen. Wenn ein Test mehrere Anfragen ausprobieren soll, ist pytest.mark.parametrize aus Python in der Praxis eine saubere Form, und einfache asserts in einer Funktion funktionieren genauso.

Führe noch einmal python -m pytest -q aus. Es endet mit 2 failed, 3 passed, 1 warning: Die beiden Fehlschläge sind die Platzhalter von Lektion 5, assert False, "not written yet", die auf Lektion 5 warten, und Check my work lässt sie aus. Klicke dann auf Check my work. Lektion 3 übergibt den Body der Anfrage an das Modell.