overpass/TASK.md

Task 18 — Testing

Rückblick Task 17: PostgresStorage

Falls alles geklappt hat, habt ihr nun eure POI's in einer lokalen PostGreSQL-Datenbank abgespeichert. Erreicht haben wir diese in einer Implementation von PostgresStorage(Storage) ohne bestehende Businesslogik in main.py etc. anzufassen. Das garantiert maximale Flexibilität und Wiederverwendbarkeit des Codes und ist deutlich wartungsfreundlicher und damit auch übersichtlicher.

Aufgabe

Bisher haben wir keinen einzigen Test für unser Miniprojekt geschrieben. Wir werden das hier auch nicht im grossen Stil und vollumfänglich machen, sondern nur exemplarisch.

UND: Wir haben noch eine 'sicherheitsrelevante' Einschränkung im Code. Im jetzigen Stand werden persönliche/private Informationen wie der username und vor allem das password im connection_string in config.yaml geschrieben. Das ist nicht ideal, weil die config ins git geschrieben wird und somit für alle (berechtigten) einsehbar ist. Das wollen und müssen wir ändern!

Konkret:

1. Speichert den privaten connection_string in einer neue angelegten .env und verwendet diesen in euerem Code unter Nutzung von load_dotenv aus (aus dem dotenv-Modul). Schaut zudem, dass euer .env in .gitignore aufgeführt ist und somit nicht von git 'getracked' wird!

2. Erstellt einen neuen Ordner tests in eurem root-Projektverzeichnis (also neben src)

3. Erstellt darin ein neues Modul tests_overpass.py

4. Wie erwähnt wollen wir nur exemplarisch wenige Tests machen:

   • in der POI-Klasse haben wir eine Klassenmethode from_row: Schreibt einen ganz einfachen Unittest, welcher überprüft, ob diese tatsächlich ein POI-Objekt zurück gibt.

       @classmethod
       def from_row(cls, row: dict) -> POI:
           """DB-Zeile → POI-Objekt (Lesen)"""
           return cls(
               id       = row["id"],
               type     = row["type"],
               poi_type = row["poi_type"],
               lat      = row["lat"],
               lon      = row["lon"],
               tags     = row["tags"] or {},
           )
   

   • im Unterricht wurden kurz Inhalte aus dem Testing mit mocks, stub und fake angesprochen. Lest das nochmals und versucht zu verstehen wie und wo man diese in unserem Projekt gebrauchen könnte und warum. Wir werden gemeinsam je ein Beispiel aus jeder dieser 3 Kategorien zusammen anschauen.

Fragen zum Nachdenken:

• Zum Projektabschluss: Bitte überlegt euch Stärken aber sicher auch Einschränkungen/Schwächen unseres Mini-Projekts. Was könnte man besser/einfacher/anders machen?