Wie Sie Unit-Tests in Flask durchführen

Unit-Tests prüfen einzelne Bausteine einer Anwendung isoliert und melden Fehler, bevor sie in die Produktion gelangen. Für Flask-Anwendungen hat sich pytest als Standard etabliert: Es kommt mit deutlich weniger Boilerplate aus als das unittest-Modul der Standardbibliothek, liefert aussagekräftige Fehlermeldungen und bringt mit Fixtures ein flexibles System zur Vorbereitung von Testdaten mit.

Dieser Leitfaden zeigt Ihnen Schritt für Schritt, wie Sie eine Flask-Anwendung testbar aufbauen, eine Testumgebung mit pytest einrichten, wiederverwendbare Fixtures über conftest.py bereitstellen, Routen und Fehlerfälle prüfen, Tests parametrisieren und die Testabdeckung messen.

Wichtigste Erkenntnisse

• Eine Application Factory (create_app()) macht eine Flask-Anwendung testbar, weil jeder Test eine eigene Instanz mit eigener Konfiguration erhält.
• Der Testclient aus app.test_client() sendet Requests direkt an die Anwendung, ohne dass ein Server laufen muss.
• Fixtures gehören in eine conftest.py im Projektwurzelverzeichnis. pytest findet sie dort automatisch, ohne dass sie importiert werden müssen.
• Setzen Sie TESTING=True in der Testkonfiguration. Damit propagiert Flask Ausnahmen, statt sie in eine generische 500-Antwort umzuwandeln.
• Mit @pytest.mark.parametrize prüfen Sie dieselbe Testfunktion mit mehreren Eingabewerten, ohne den Code zu duplizieren.
• pytest --cov=app --cov-report=term-missing zeigt nicht nur die Abdeckung in Prozent, sondern auch die konkret ungetesteten Zeilennummern.
• Bei ModuleNotFoundError: No module named 'app' fehlt in der Regel das Projektverzeichnis im Suchpfad. Eine pytest.ini mit pythonpath = . behebt das dauerhaft.

Voraussetzungen

Bevor Sie beginnen, benötigen Sie Folgendes:

• Einen Server mit Ubuntu 24.04 und einen Nicht-Root-Benutzer mit sudo-Rechten.
• Python 3.8 oder höher auf dem System installiert.
• Grundkenntnisse in der Nutzung der Linux-Befehlszeile.
• Grundlegendes Verständnis der Python-Programmierung und des Flask-Frameworks.

Warum pytest für Flask-Tests?

Python bringt mit unittest bereits ein Test-Framework in der Standardbibliothek mit. Für Flask-Projekte greifen die meisten Teams dennoch zu pytest. Die Gründe:

• Weniger Boilerplate: Tests sind einfache Funktionen mit assert-Anweisungen. Sie brauchen weder Testklassen noch Methoden wie assertEqual oder assertTrue.
• Aussagekräftige Fehlermeldungen: Schlägt ein assert fehl, zeigt pytest die tatsächlichen Werte beider Seiten an, statt nur „AssertionError“ zu melden.
• Fixtures statt setUp/tearDown: Fixtures lassen sich kombinieren, verschachteln und pro Test, pro Modul oder pro Session wiederverwenden. Das ist deutlich flexibler als die starren setUp- und tearDown-Methoden von unittest.
• Parametrisierung: Eine einzelne Testfunktion lässt sich mit einem Dekorator gegen beliebig viele Eingabewerte laufen lassen.
• Plugin-Ökosystem: Erweiterungen wie pytest-cov für Coverage oder pytest-xdist für parallele Ausführung sind mit einem Befehl installiert.
• Automatische Erkennung: pytest findet Dateien nach dem Muster test_*.py und Funktionen nach dem Muster test_* selbstständig.

Hinweis: pytest führt bestehende unittest-Testklassen ohne Anpassung mit aus. Sie können also schrittweise migrieren, statt eine gewachsene Test-Suite auf einmal umzuschreiben.

Schritt 1 – Projektumgebung einrichten

Prüfen Sie zunächst, ob Python 3 auf dem System vorhanden ist:

root@ubuntu:~# python3 --version

Ausgabe:

Python 3.12.3

Falls Python 3 fehlt, installieren Sie es zusammen mit dem Modul für virtuelle Umgebungen:

root@ubuntu:~# sudo apt update
root@ubuntu:~# sudo apt install python3 python3-venv

Legen Sie anschließend ein Projektverzeichnis an und wechseln Sie hinein:

root@ubuntu:~# mkdir flask_pytest_app
root@ubuntu:~# cd flask_pytest_app

Erstellen und aktivieren Sie eine virtuelle Umgebung. Dadurch bleiben die Projektabhängigkeiten vom System-Python getrennt:

root@ubuntu:~/flask_pytest_app# python3 -m venv venv
root@ubuntu:~/flask_pytest_app# source venv/bin/activate

Installieren Sie Flask und pytest in der aktiven Umgebung:

(venv) root@ubuntu:~/flask_pytest_app# pip install Flask pytest

Überprüfen Sie die installierten Versionen:

(venv) root@ubuntu:~/flask_pytest_app# pytest --version

Ausgabe:

pytest 8.3.4

Schritt 2 – Flask-Anwendung erstellen

Damit sich eine Flask-Anwendung sauber testen lässt, sollte sie nicht beim Import bereits eine globale Instanz erzeugen. Stattdessen kapseln Sie den Aufbau in einer Funktion, der sogenannten Application Factory. Jeder Test kann dann eine frische Instanz mit eigener Konfiguration anfordern.

Erstellen Sie die Datei app.py mit folgendem Inhalt:

app.py

from flask import Flask, jsonify, request


def create_app(test_config=None):
    app = Flask(__name__)

    if test_config is not None:
        app.config.update(test_config)

    @app.route("/")
    def home():
        return jsonify(message="Hello, Flask!")

    @app.route("/multiply/<int:x>/<int:y>")
    def multiply(x, y):
        return jsonify(result=x * y)

    @app.route("/users", methods=["POST"])
    def create_user():
        data = request.get_json(silent=True) or {}
        name = data.get("name")

        if not name:
            return jsonify(error="name is required"), 400

        return jsonify(id=1, name=name), 201

    return app


if __name__ == "__main__":
    create_app().run(debug=True)

Die Anwendung stellt drei Routen bereit:

• GET / gibt eine feste Begrüßung als JSON zurück.
• GET /multiply/<x>/<y> multipliziert zwei Ganzzahlen aus der URL.
• POST /users erwartet ein JSON-Objekt mit dem Feld name und antwortet mit Status 201. Fehlt das Feld, folgt Status 400.

Starten Sie die Anwendung zur Kontrolle einmal manuell:

(venv) root@ubuntu:~/flask_pytest_app# python app.py

Ausgabe:

 * Serving Flask app 'app'
 * Debug mode: on
 * Running on http://127.0.0.1:5000 (Press CTRL+C to quit)

Beenden Sie den Server anschließend mit STRG+C. Für die Tests wird er nicht benötigt.

Schritt 3 – Fixtures in conftest.py anlegen

Fast jeder Test benötigt dieselben zwei Dinge: eine Anwendungsinstanz und einen Testclient. Statt diese in jeder Testdatei neu aufzubauen, definieren Sie sie einmal als Fixtures in einer Datei namens conftest.py. pytest lädt diese Datei automatisch und stellt die enthaltenen Fixtures allen Tests im selben Verzeichnisbaum zur Verfügung – ein Import ist nicht nötig.

Legen Sie zunächst ein Verzeichnis für die Tests an:

(venv) root@ubuntu:~/flask_pytest_app# mkdir tests

Erstellen Sie nun conftest.py im Projektwurzelverzeichnis:

conftest.py

import pytest

from app import create_app


@pytest.fixture
def app():
    """Erzeugt für jeden Test eine frische Anwendungsinstanz."""
    application = create_app({"TESTING": True})
    yield application


@pytest.fixture
def client(app):
    """Stellt einen Testclient bereit, der Requests ohne Server absetzt."""
    return app.test_client()

Beachten Sie drei Punkte:

• TESTING=True weist Flask an, Ausnahmen an den Test durchzureichen, statt sie in eine generische 500-Antwort zu verwandeln. Ohne diese Einstellung sehen Sie im Fehlerfall nur den Statuscode und nicht die eigentliche Ursache.
• Die Fixture client fordert die Fixture app als Parameter an. pytest löst diese Abhängigkeit selbstständig auf.
• Da beide Fixtures den Standard-Scope function verwenden, bekommt jeder Test eine eigene Instanz. Tests können sich dadurch nicht gegenseitig beeinflussen.

Hinweis: yield statt return ist dann sinnvoll, wenn nach dem Test noch aufgeräumt werden muss – etwa um eine Testdatenbank zu löschen. Der Code hinter dem yield läuft nach jedem Test, auch wenn dieser fehlschlägt.

Schritt 4 – Erste Unit-Tests schreiben

Erstellen Sie die Datei tests/test_routes.py. pytest erkennt sie automatisch, weil der Dateiname mit test_ beginnt:

tests/test_routes.py

def test_home_returns_greeting(client):
    response = client.get("/")

    assert response.status_code == 200
    assert response.get_json() == {"message": "Hello, Flask!"}


def test_home_returns_json_content_type(client):
    response = client.get("/")

    assert response.content_type == "application/json"


def test_multiply_returns_product(client):
    response = client.get("/multiply/6/7")

    assert response.status_code == 200
    assert response.get_json()["result"] == 42


def test_unknown_route_returns_404(client):
    response = client.get("/does-not-exist")

    assert response.status_code == 404

Jede Testfunktion nimmt client als Parameter entgegen. pytest erkennt den Namen, findet die passende Fixture in conftest.py und übergibt das Ergebnis automatisch.

Das Antwortobjekt des Testclients bietet unter anderem diese Eigenschaften:

• response.status_code – der HTTP-Statuscode als Ganzzahl.
• response.get_json() – der Response-Body als Python-Dictionary.
• response.data – der rohe Body als Bytes, nützlich für HTML-Antworten.
• response.headers – die Response-Header als Dictionary-ähnliches Objekt.

Hinweis: Die Route /multiply/<int:x>/<int:y> akzeptiert keine negativen Zahlen. Der Konverter int von Werkzeug erkennt standardmäßig nur Ziffernfolgen, sodass /multiply/-2/4 mit Status 404 beantwortet wird. Wenn Sie negative Werte zulassen möchten, verwenden Sie <int(signed=True):x>.

Schritt 5 – Tests ausführen

Führen Sie pytest im Projektwurzelverzeichnis aus:

(venv) root@ubuntu:~/flask_pytest_app# pytest

Ausgabe:

========================= test session starts =========================
platform linux -- Python 3.12.3, pytest-8.3.4, pluggy-1.5.0
rootdir: /root/flask_pytest_app
collected 4 items

tests/test_routes.py ....                                       [100%]

========================== 4 passed in 0.12s ==========================

Jeder Punkt steht für einen bestandenen Test. Für eine ausführlichere Ausgabe mit Testnamen verwenden Sie die Option -v:

(venv) root@ubuntu:~/flask_pytest_app# pytest -v

Ausgabe:

tests/test_routes.py::test_home_returns_greeting PASSED         [ 25%]
tests/test_routes.py::test_home_returns_json_content_type PASSED [ 50%]
tests/test_routes.py::test_multiply_returns_product PASSED      [ 75%]
tests/test_routes.py::test_unknown_route_returns_404 PASSED     [100%]

Weitere nützliche Optionen im Alltag:

• pytest tests/test_routes.py – führt nur eine bestimmte Datei aus.
• pytest -k multiply – führt nur Tests aus, deren Name den Text multiply enthält.
• pytest -x – bricht beim ersten Fehlschlag ab.
• pytest -s – zeigt Ausgaben von print() an, die pytest sonst unterdrückt.

Wie ein fehlgeschlagener Test aussieht

Ändern Sie testweise eine Erwartung, um die Fehlerausgabe kennenzulernen. Ersetzen Sie in test_multiply_returns_product den Wert 42 durch 40 und führen Sie pytest erneut aus:

Ausgabe:

=============================== FAILURES ==============================
_____________________ test_multiply_returns_product ___________________

client = <FlaskClient >

    def test_multiply_returns_product(client):
        response = client.get("/multiply/6/7")

        assert response.status_code == 200
>       assert response.get_json()["result"] == 40
E       assert 42 == 40

tests/test_routes.py:18: AssertionError
======================= 1 failed, 3 passed in 0.14s ===================

pytest zeigt die fehlgeschlagene Zeile mit > an und darunter beide konkreten Werte (assert 42 == 40). Genau diese Introspektion macht die einfachen assert-Anweisungen so praktisch. Setzen Sie den Wert anschließend wieder auf 42 zurück.

Schritt 6 – POST-Requests und Fehlerfälle testen

Ein realistischer Test deckt nicht nur den Erfolgsfall ab, sondern auch fehlerhafte Eingaben. Erstellen Sie dazu die Datei tests/test_users.py:

tests/test_users.py

def test_create_user_returns_201(client):
    response = client.post("/users", json={"name": "Alice"})

    assert response.status_code == 201
    assert response.get_json() == {"id": 1, "name": "Alice"}


def test_create_user_without_name_returns_400(client):
    response = client.post("/users", json={})

    assert response.status_code == 400
    assert response.get_json()["error"] == "name is required"


def test_create_user_without_body_returns_400(client):
    response = client.post("/users")

    assert response.status_code == 400


def test_get_on_users_is_not_allowed(client):
    response = client.get("/users")

    assert response.status_code == 405

Der Parameter json= serialisiert das übergebene Dictionary und setzt den Header Content-Type: application/json automatisch. Sie müssen den Body also nicht selbst mit json.dumps() aufbereiten.

Der letzte Test prüft Status 405 (Method Not Allowed). Flask erzeugt diese Antwort selbstständig, weil die Route /users nur für POST registriert ist. Solche Tests dokumentieren die erwartete Schnittstelle und schlagen an, sobald jemand versehentlich weitere Methoden freischaltet.

Führen Sie beide Testdateien zusammen aus:

(venv) root@ubuntu:~/flask_pytest_app# pytest

Ausgabe:

collected 8 items

tests/test_routes.py ....                                       [ 50%]
tests/test_users.py ....                                        [100%]

========================== 8 passed in 0.18s ==========================

Schritt 7 – Parametrisierte Tests

Um dieselbe Logik mit mehreren Eingabewerten zu prüfen, brauchen Sie keine kopierten Testfunktionen. Der Dekorator @pytest.mark.parametrize erzeugt aus einer Funktion so viele Testfälle, wie Sie Wertepaare angeben.

Ergänzen Sie tests/test_routes.py um folgenden Code:

tests/test_routes.py

import pytest


@pytest.mark.parametrize(
    "x, y, expected",
    [
        (2, 3, 6),
        (0, 5, 0),
        (1, 1, 1),
        (12, 12, 144),
    ],
)
def test_multiply_with_various_inputs(client, x, y, expected):
    response = client.get(f"/multiply/{x}/{y}")

    assert response.status_code == 200
    assert response.get_json()["result"] == expected

Der Import von pytest gehört dabei an den Anfang der Datei. Führen Sie die Tests mit -v aus, um die einzelnen Fälle zu sehen:

(venv) root@ubuntu:~/flask_pytest_app# pytest tests/test_routes.py -v

Ausgabe:

tests/test_routes.py::test_multiply_with_various_inputs[2-3-6] PASSED
tests/test_routes.py::test_multiply_with_various_inputs[0-5-0] PASSED
tests/test_routes.py::test_multiply_with_various_inputs[1-1-1] PASSED
tests/test_routes.py::test_multiply_with_various_inputs[12-12-144] PASSED

Jeder Wertesatz erscheint als eigener Testfall mit den Parametern im Namen. Schlägt einer fehl, sehen Sie sofort, welche Eingabe betroffen ist – ein deutlicher Vorteil gegenüber einer Schleife innerhalb einer einzigen Testfunktion, die beim ersten Fehler abbricht.

Schritt 8 – Test-Coverage messen

Die Testabdeckung zeigt, welche Codezeilen beim Testlauf tatsächlich ausgeführt wurden. Installieren Sie dafür das Plugin pytest-cov:

(venv) root@ubuntu:~/flask_pytest_app# pip install pytest-cov

Starten Sie den Testlauf mit Coverage-Bericht:

(venv) root@ubuntu:~/flask_pytest_app# pytest --cov=app --cov-report=term-missing

Ausgabe:

---------- coverage: platform linux, python 3.12.3 -----------
Name     Stmts   Miss  Cover   Missing
--------------------------------------
app.py      18      1    94%   38
--------------------------------------
TOTAL       18      1    94%

========================= 12 passed in 0.26s =========================

Die Spalte Missing nennt die Zeilennummern, die kein Test erreicht hat – hier der Block if __name__ == "__main__", der beim Import nie ausgeführt wird. Für einen durchsuchbaren HTML-Bericht verwenden Sie stattdessen:

(venv) root@ubuntu:~/flask_pytest_app# pytest --cov=app --cov-report=html

Der Bericht liegt anschließend unter htmlcov/index.html und markiert ungetestete Zeilen farblich.

Hinweis: Eine hohe Abdeckung bedeutet nicht automatisch gute Tests. Sie zeigt nur, dass Zeilen ausgeführt wurden – nicht, dass ihr Ergebnis auch geprüft wurde. Nutzen Sie die Zahl als Hinweis auf blinde Flecken, nicht als Qualitätsziel.

Häufige Fehler beheben

ModuleNotFoundError: No module named 'app'

pytest fügt das Wurzelverzeichnis nicht in jeder Konstellation automatisch dem Suchpfad hinzu. Der Import from app import create_app schlägt dann fehl.

Legen Sie eine pytest.ini im Projektwurzelverzeichnis an. Damit ist die Konfiguration dauerhaft festgehalten und gilt für alle Beteiligten:

pytest.ini

[pytest]
testpaths = tests
pythonpath = .

Die Option pythonpath setzt pytest ab Version 7.0 voraus. Bei älteren Versionen genügt eine leere Datei tests/__init__.py oder der Aufruf über python -m pytest, weil das aktuelle Verzeichnis dabei ohnehin im Suchpfad landet.

fixture 'client' not found

Diese Meldung bedeutet, dass pytest die Fixture nicht sieht. Häufigste Ursachen:

• Die conftest.py liegt außerhalb des Verzeichnisbaums, in dem die Tests stehen. Legen Sie sie im Projektwurzelverzeichnis ab, dann gilt sie für alle Unterverzeichnisse.
• Der Dateiname ist falsch geschrieben, etwa conf_test.py. Nur der exakte Name conftest.py wird automatisch geladen.
• Der Dekorator @pytest.fixture fehlt über der Funktion.

Tests werden nicht gefunden

pytest sammelt standardmäßig nur Dateien nach dem Muster test_*.py oder *_test.py und darin Funktionen, die mit test_ beginnen. Eine Datei namens routes_tests.py oder eine Funktion check_home() wird stillschweigend ignoriert. Prüfen Sie im Zweifel, was pytest überhaupt einsammelt:

(venv) root@ubuntu:~/flask_pytest_app# pytest --collect-only

Working outside of application context

Manche Flask-Objekte wie current_app, g oder url_for benötigen einen aktiven Anwendungskontext. Innerhalb eines Requests über den Testclient ist dieser vorhanden. Prüfen Sie dagegen direkt eine Funktion, die solche Objekte nutzt, aktivieren Sie den Kontext selbst:

def test_url_for_home(app):
    with app.app_context():
        from flask import url_for

        with app.test_request_context():
            assert url_for("home") == "/"

Tests beeinflussen sich gegenseitig

Wenn Tests einzeln bestehen, in Kombination aber fehlschlagen, teilen sie vermutlich einen Zustand. Typische Ursache ist eine Fixture mit scope="session" oder scope="module", die eine Datenbank oder eine Anwendungsinstanz über mehrere Tests hinweg wiederverwendet. Belassen Sie Fixtures im Standard-Scope function, solange kein messbarer Performance-Grund dagegen spricht.

FAQs

Was ist der Unterschied zwischen dem Testclient und einem echten HTTP-Request?

Der Testclient aus app.test_client() ruft die WSGI-Anwendung direkt auf. Es wird kein Netzwerk-Socket geöffnet und kein Server gestartet, weshalb Tests sehr schnell laufen und keinen Port belegen.

Die Anwendung selbst bemerkt keinen Unterschied: Routing, Request-Parsing, Before- und After-Request-Handler sowie Fehlerbehandlung laufen identisch ab. Was der Testclient nicht abdeckt, ist alles außerhalb der Anwendung – etwa TLS-Terminierung, Reverse-Proxy-Header oder das Verhalten des WSGI-Servers unter Last.

Warum sollte ich eine Application Factory verwenden?

Ohne Factory entsteht die Flask-Instanz beim Import des Moduls. Ihre Konfiguration steht damit fest, bevor der Test sie beeinflussen kann, und alle Tests teilen dieselbe Instanz.

Mit create_app() übergeben Sie pro Test eine eigene Konfiguration, etwa eine separate Testdatenbank. Jeder Test startet mit einem sauberen Zustand, und Nebenwirkungen zwischen Tests entfallen.

Wofür ist die Einstellung TESTING=True gedacht?

TESTING=True sorgt dafür, dass Flask Ausnahmen aus dem Anwendungscode weiterreicht, statt sie abzufangen und in eine generische 500-Antwort umzuwandeln. Im Fehlerfall sehen Sie dadurch den vollständigen Traceback mit der eigentlichen Ursache.

Zusätzlich deaktivieren einige Flask-Erweiterungen anhand dieses Flags Verhalten, das im Test stört – beispielsweise den CSRF-Schutz von Flask-WTF.

Wo muss die Datei conftest.py liegen?

Legen Sie conftest.py im Projektwurzelverzeichnis ab. Fixtures daraus stehen dann allen Tests in diesem Verzeichnis und allen Unterverzeichnissen zur Verfügung, ohne dass ein Import nötig ist.

Größere Projekte können zusätzliche conftest.py-Dateien in Unterverzeichnissen anlegen. Die jeweils näher gelegene Datei hat Vorrang, sodass sich Fixtures gezielt für einen Teilbereich überschreiben lassen.

Wie teste ich Routen, die eine Datenbank verwenden?

Übergeben Sie der Factory eine Testkonfiguration mit eigener Datenbank-URL und bauen Sie das Schema in einer Fixture auf, bevor der Test läuft. Nach dem yield räumen Sie wieder auf, damit jeder Test mit einem definierten Zustand startet.

Eine SQLite-Datenbank im Arbeitsspeicher (sqlite:///:memory:) eignet sich gut für schnelle Testläufe. Wenn Ihre Anwendung datenbankspezifische Funktionen nutzt, sollten Sie stattdessen dasselbe Datenbanksystem wie in der Produktion einsetzen, um abweichendes Verhalten zu vermeiden.

Kann ich bestehende unittest-Tests mit pytest ausführen?

Ja. pytest erkennt Klassen, die von unittest.TestCase erben, und führt deren Testmethoden mit aus. Sie können eine bestehende Suite also unverändert unter pytest laufen lassen.

Einschränkung: pytest-Fixtures lassen sich in unittest-Testklassen nicht per Parameter anfordern. Neue Tests schreiben Sie deshalb besser gleich als einfache Funktionen.

Wie viel Test-Coverage ist ausreichend?

Eine allgemeingültige Zahl gibt es nicht. Viele Teams orientieren sich an 80 Prozent für Anwendungscode, wobei Konfiguration und Einstiegspunkte üblicherweise ausgenommen werden.

Aussagekräftiger als die Gesamtquote ist die Spalte Missing im Bericht. Prüfen Sie dort gezielt, ob wichtige Verzweigungen – vor allem Fehlerpfade und Validierungen – ungetestet geblieben sind.

Wie führe ich die Tests automatisiert in einer CI-Pipeline aus?

Installieren Sie die Abhängigkeiten in der Pipeline und rufen Sie pytest mit einem Schwellenwert für die Abdeckung auf. Der folgende Befehl beendet den Lauf mit einem Fehlercode, sobald die Abdeckung unter 80 Prozent fällt:

pytest --cov=app --cov-report=term-missing --cov-fail-under=80

Halten Sie die Abhängigkeiten dafür in einer requirements.txt fest, damit lokale Läufe und CI-Läufe dieselben Versionen verwenden.

Fazit

Sie haben eine Flask-Anwendung mit einer Application Factory aufgebaut, wiederverwendbare Fixtures in einer conftest.py bereitgestellt und Unit-Tests für Erfolgsfälle, Fehlerfälle und mehrere Eingabewerte geschrieben. Ergänzend haben Sie die Testabdeckung gemessen und die häufigsten Stolpersteine kennengelernt.

Der entscheidende Baustein für testbaren Flask-Code ist die Factory: Weil jeder Test eine eigene Anwendungsinstanz mit eigener Konfiguration erhält, bleiben Tests unabhängig voneinander und liefern reproduzierbare Ergebnisse.

Als nächsten Schritt bietet es sich an, den Testlauf in eine CI-Pipeline einzubinden, damit jede Änderung automatisch geprüft wird. Weiterführende Informationen finden Sie in der offiziellen Dokumentation von Flask und pytest.