🏆Abschlussprojekt: Abschlussprojekt: Das Werkzeug fertigstellen und prüfen

Das ist der letzte Bauschritt. Alles danach dient der Übergabe des Projekts.

Vervollständige practice_report.py, sodass alle Teile zusammenarbeiten: der Cache mit seinen Vorgaben, Aktualität anhand übergebener Zeit, die Auswahltabelle mit sechs Zeilen, Zusammenfassung und Bericht sowie die CLI-Grenze, die entscheidet, was in welcher Reihenfolge geschrieben wird.

Führe anschließend beide Testsuiten aus:

python -m pytest -q

Beide Module sollten Tests finden und bestehen. tests/test_api_catalog.py hast du aus Kapitel 12 übernommen; es sollte unverändert geblieben sein. tests/test_practice_report.py hast du selbst geschrieben.

Belege, dass es einen Ortswechsel übersteht

Diese Lektion hat keinen Netzwerkzugriff. Die Laufzeitumgebung der Website stellt die festgelegten Requests- und pytest-Versionen bereits bereit. Verwende deshalb ihr python, um eine kopierte Quellstruktur ohne Paketinstallation zu prüfen. Kapitel 12 hat den Neuaufbau einer Umgebung behandelt; die nächste Lektion wiederholt diesen Teil auf deinem eigenen Rechner.

Kopiere die zehn selbst verfassten Dateien in einen neuen Ordner mit einem Leerzeichen und Nicht-ASCII-Text im Namen. Führe dort die Tests und den Offline-Modus aus:

mkdir -p "/tmp/Fresh Café Report Project/tests"
mkdir -p "/tmp/Fresh Café Report Project/data"
cp API_CONTRACT.md README.md api_catalog.py practice_report.py pl_check.py \
   requirements.txt requirements-dev.txt "/tmp/Fresh Café Report Project/"
cp data/offline-page.json "/tmp/Fresh Café Report Project/data/"
cp tests/test_api_catalog.py tests/test_practice_report.py "/tmp/Fresh Café Report Project/tests/"
cd "/tmp/Fresh Café Report Project"
python -m pytest -q
python practice_report.py report.txt --offline-source data/offline-page.json
cd /workspace

Diese Befehle führen die Suite erneut aus und erzeugen einen Offline-Bericht aus dem kopierten Stammverzeichnis. Beides sollte sich genau wie am ursprünglichen Ort verhalten. Falls nicht, hängt etwas in deinem Code vom Speicherort ab. Das findest du besser jetzt heraus, bevor du das Projekt jemandem schickst.

Probiere die fehleranfälligen Pfade aus

Führe in dieser Sitzung ohne Netzwerk den Offline-Pfad aus:

python practice_report.py report.txt --offline-source data/offline-page.json
cat report.txt

Der Bericht sollte source: offline und fetched_at: none anzeigen. Der Befehl darf keine Cache-Datei erzeugen oder verändern. Ein vorhandener Cache aus früherer Arbeit bleibt unverändert.

Verwende deine Fake-HTTP-Tests für die übrigen Auswahlzeilen. Ein aktueller Cache sollte null Aufrufe aufzeichnen, ein fehlender einen. Ein veralteter Cache sollte nur bei den dokumentierten Fehlern als Ersatz dienen, und --refresh muss einmal abrufen, ohne zurückzugreifen. Übergib now_epoch, damit sich das Aktualitätsergebnis während eines Tests nicht ändern kann. Ein echter neuer Abruf kann in dieser Sitzung ohne Netzwerk nicht gelingen.

Räume vor der Abgabe auf

Lösche erzeugte Cache- und Berichtsdateien aus dem gespeicherten Arbeitsbereich. Das kopierte Stammverzeichnis liegt unter /tmp und wird mit der Sitzung verworfen. .venv, __pycache__ und .pytest_cache sind abgeleiteter Zustand und gehören nicht in die selbst verfasste Dateistruktur.

Das gespeicherte Projekt sollte genau zehn selbst verfasste Dateien enthalten und sonst nichts:

API_CONTRACT.md
README.md
api_catalog.py
practice_report.py
pl_check.py
requirements.txt
requirements-dev.txt
data/offline-page.json
tests/test_api_catalog.py
tests/test_practice_report.py

Ein erzeugter Cache ist kein Beleg dafür, dass das Werkzeug funktioniert. Er ist ein Überbleibsel. Die zehn Dateien oben sind das Projekt; alles andere erzeugt das Projekt selbst.

Drücke Check my work, wenn die Testsuiten grün und die Dateistruktur sauber sind.

Wenn ein Test fehlschlägt und du nicht siehst, warum, bitte Monty, die fehlgeschlagene Assertion zu lesen und zu sagen, welche der sechs Auswahlzeilen sie prüft. Die Zeile zu benennen heißt meist, den Fehler zu benennen.