Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Unit-Tests Integrationstests und End-to-End-Tests automatisieren

QR-Code

Einleitung

Zielgruppe: Auszubildende im zweiten bis dritten Ausbildungsjahr. Voraussetzungen: A1 oder Grundlagen in Python, Dateien, Git und einfachen Tests. Zeitbedarf: etwa vier bis sechs Unterrichtseinheiten zuzüglich eines Praxisprojekts. Lernprodukt: eine lokal ausführbare Testsuite der synthetischen Messdaten-App vom Funktionsaufruf bis zur Importoberfläche.

Du überprüfst Programme systematisch und reproduzierbar. Ausgangspunkt ist die vorhandene MOOCwiki-Grundlage, die du zum Wiederholen nutzen kannst. Der Inhalt dieser verlinkten Seite konnte bei der Recherche nicht vollständig abgerufen werden; Aussagen über ihre Einzelheiten werden daher nicht vorausgesetzt. Wiederhole nur die Begriffe Funktion, Datei, Git und `assert`. Anschließend entwickelst du neue Tests, erklärst ihre Grenzen und lieferst einen dokumentierten echten Testlauf.

Leitfrage: Wann belegt ein grüner Test tatsächlich eine fachlich richtige Eigenschaft? Entscheidend sind unabhängige Sollwerte, nachvollziehbare Ein- und Ausgaben und ein real ausgeführter Test statt einer bloßen Behauptung. Alle Daten sind erfunden. Du brauchst kein bezahltes KI-Konto, keine produktiven Systeme und keine reale Maschinensteuerung. Dieses unabhängige Bildungsangebot ist keine offizielle Liebherr- oder IHK-Zertifizierung.

Testebenen und verlässliche Sollwerte

Unit, Integration und End-to-End unterscheiden

Ein Unit-Test prüft eine kleine Einheit, etwa `parse_value("0")`. Ein Integrationstest prüft das Zusammenspiel mehrerer Teile, etwa CSV-Lesen, Kopfzeilenprüfung und Wertvalidierung. Ein End-to-End-Test (E2E) startet die Anwendung aus der Sicht einer Person, zum Beispiel über die Kommandozeile mit einer Beispieldatei, und kontrolliert den sichtbaren Erfolg oder Fehler. E2E bezeichnet den vollständigen Nutzerweg; dafür ist keine öffentliche Website erforderlich.

Bildnachweis: Abbe98, Testing Pyramid.svg, CC BY-SA 4.0; Lizenz. Die Abbildung ist eine Heuristik, kein festes Mengenverhältnis. Ohne Bild: Unit prüft eine Funktion, Integration die Zusammenarbeit und E2E einen ganzen Nutzerpfad.

Testorakel, Grenzfall und Testnachweis

Ein Testorakel ist die begründete Erwartung, mit der ein tatsächliches Ergebnis verglichen wird. Lege dieses Soll fest, bevor du die Implementierung liest oder änderst: Für Werte von 0 bis 100 sind 0 und 100 gültig; -0.01 und 100.01 ungültig; nicht endliche Werte wie `nan` ungültig. Prüfe den Fall direkt an der Grenze und knapp außerhalb. Ein aus dem Produktivcode kopierter Algorithmus ist kein unabhängiger Sollwert.

Ein Testfall benennt Eingabe, erwartete Ausgabe bzw. Ausnahme, Ausführungsumgebung und beobachtetes Ergebnis. Die Testabdeckung misst ausgeführten Code, aber nicht dessen inhaltliche Richtigkeit; auch 100 Prozent Abdeckung garantiert keine Fehlerfreiheit. Zusätzliche Negativtests prüfen, ob fehlerhafte Eingaben sicher abgewiesen werden.

Schwarzbox und Weißbox

Beim Black-Box-Test leitest du Erwartungen aus Anforderungen und Nutzersicht ab. Beim White-Box-Test kennst du zusätzlich Verzweigungen und innere Struktur. Kombiniere beides: Grenzen stammen aus dem Fachvertrag, Zweigtests aus dem Code. Keine der beiden Perspektiven ersetzt die andere.

Bildnachweis: Marekventur, Software test methods.svg, CC BY-SA 3.0; Lizenz. Ohne Bild: Schwarzbox prüft äußeres Verhalten, Weißbox berücksichtigt interne Pfade.

Geführtes Beispiel: die Messwertfunktion isoliert testen

Fachvertrag und synthetische Testdaten

Die lokale Übungsanwendung importiert nur synthetische Zahlenwerte. Fachvertrag der Funktion `parse_value(text)`: Erwartet wird eine Textzahl mit Punkt als Dezimaltrennzeichen. Zulässig sind ausschließlich endliche Zahlen im inklusiven Intervall 0 bis 100. Bei anderem Inhalt wird `ValueError` ausgelöst. Die Funktion führt weder Dateioperationen noch Netzwerkzugriffe durch. Schreibe diesen Vertrag als unabhängige Grundlage auf.

Datei `messwerte.py` – bewusst kurze Beispielimplementierung:

import math

def parse_value(text):
    value = float(text)
    if not math.isfinite(value) or not (0 <= value <= 100):
        raise ValueError("Wert außerhalb des gültigen Bereichs")
    return value

Hinweis: `float("abc")` löst ebenfalls `ValueError` aus, jedoch mit einer anderen Meldung. Für dieses Lernprodukt ist der Ausnahmetyp vereinbart, nicht die exakte Fehlermeldung. `float` akzeptiert weitere Schreibweisen; eine strenge Prüfung des Zeichenformats wäre eine zusätzliche Anforderung.

Unit-Test mit pytest und echten Grenzfällen

Datei `test_messwerte.py`:

import pytest
from messwerte import parse_value

@pytest.mark.parametrize("eingabe,erwartet", [
    ("0", 0.0),
    ("100", 100.0),
    ("50.25", 50.25),
])
def test_zulaessige_werte(eingabe, erwartet):
    assert parse_value(eingabe) == erwartet

@pytest.mark.parametrize("eingabe", [
    "-0.01", "100.01", "nan", "inf", "abc"
])
def test_ungueltige_werte(eingabe):
    with pytest.raises(ValueError):
        parse_value(eingabe)

Ausführung: Installiere lokal in einer isolierten Python-Umgebung `pytest` nach der offiziellen Anleitung; starte `python -m pytest -q`. Halte Version, Testanzahl, Rückgabecode und Zeit des tatsächlichen Laufs fest. Die gezeigten Erwartungen sind ein zu prüfendes Beispiel, kein behauptetes Laufprotokoll. Bei Python- und pytest-Versionen können Details der Ausgabe abweichen.

Vertiefung: Teste `"-0"`, leeren Text und sehr lange Zahlenfolgen. Überlege, ob `" 5 "` oder wissenschaftliche Schreibweise fachlich erlaubt sein sollen. Ändere den Vertrag nicht stillschweigend, nur damit ein Test grün wird.

Test zuerst und dann verbessern

Bei testgetriebener Entwicklung formulierst du zunächst einen scheiternden, sinnvoll begründeten Test, implementierst die kleinste passende Änderung und verbesserst danach den Code bei weiter grünen Tests. Ein zunächst roter Test ist kein Makel, sondern kann nachweisen, dass die neue Anforderung bislang fehlt. Prüfe, ob ein absichtlich eingefügter Grenzfehler von deiner Testsuite entdeckt wird.

Bildnachweis: MovGP0, Testgetriebener Entwicklungsprozess.svg, auf Commons als freie Weiterverwendung durch den Urheber gekennzeichnet; Rechteangaben. Ohne Bild: Test schreiben, Ausfall prüfen, Code korrigieren, erneut testen und verbessern.

Erklärvideo (Englisch): Pytest-Einführung mit Assertions, Ausnahmen, Fixtures und Mocks von pixegami, veröffentlicht 2022; das kostenlose Video setzt kein KI-Konto voraus.

Video direkt öffnen. Textalternative: Siehe die Unit-Tests oben und die pytest-Textanleitung. Video kann regional oder zeitweise nicht verfügbar sein; die Verfügbarkeit wurde anhand des öffentlichen Videoeintrags recherchiert, nicht durch einen Abspieltest auf jedem Endgerät.

Integrationstests an CSV- und Importgrenzen

Verträge an der Schnittstelle

Die Komponente `import_csv(text)` soll eine CSV mit der Kopfzeile `zeit,wert` lesen. Jede Zeile braucht ein nicht leeres Zeitlabel sowie einen gültigen Wert. Im Modell sind Zeitlabels absichtlich einfache Zeichenketten, keine zertifizierten Zeitstempel. Bei falscher Kopfzeile, fehlendem Wert oder Zusatzspalten muss sie `ValueError` auslösen. Es gibt keine echten Geräte, keine realen Betriebsdaten und keine Fernverbindung.

Datei `importer.py`:

import csv
import io
from messwerte import parse_value

def import_csv(text):
    reader = csv.DictReader(io.StringIO(text))
    if reader.fieldnames != ["zeit", "wert"]:
        raise ValueError("Falsche CSV-Kopfzeile")
    daten = []
    for zeile in reader:
        if set(zeile) != {"zeit", "wert"}:
            raise ValueError("Fehlerhafte Spaltenanzahl")
        zeit = zeile["zeit"]
        if not zeit or not zeit.strip():
            raise ValueError("Zeitlabel fehlt")
        daten.append((zeit, parse_value(zeile["wert"])))
    return daten

Bewusste Designgrenze: Die Funktion speichert keine Datei und validiert keine Zeitsemantik; beides würde eigene Anforderungen benötigen. `csv.DictReader` liefert bei Zeilen mit überzähligen Feldern zusätzliche Schlüssel, die obige Prüfung erkennt. Bei einer fehlenden Spalte gibt `parse_value(None)` in Python einen `TypeError` statt des vereinbarten `ValueError` zurück: Das ist ein absichtlich aufzuspürender Integrationsfehler, nicht als erfolgreich behauptetes Verhalten.

Erst fehlschlagenden Schnittstellentest schreiben

import pytest
from importer import import_csv

def test_import_zwei_werte():
    assert import_csv("zeit,wert\nT1,0\nT2,100\n") == [
        ("T1", 0.0), ("T2", 100.0)
    ]

def test_falsche_kopfzeile():
    with pytest.raises(ValueError):
        import_csv("zeit,messwert\nT1,50\n")

def test_fehlende_spalte():
    with pytest.raises(ValueError):
        import_csv("zeit,wert\nT1\n")

Führe `python -m pytest -q` aus. Der letzte Test soll beim Ausgangscode scheitern, weil die fehlende Zelle einen `TypeError` verursacht. Dokumentiere die reale Fehlermeldung. Verbessere dann `import_csv`: Kontrolliere vor `parse_value`, ob `zeile["wert"] is None`, und löse in diesem Fall `ValueError` aus. Führe alle Tests erneut aus und dokumentiere den Unterschied. So prüfst du einen konkreten Schnittstellenfehler statt nur den glücklichen Pfad.

Weitere Fälle: leere Datei; nur Kopfzeile; mehrere Zeilen; zusätzliche Spalte; falsche Reihenfolge; leeres Zeitlabel; Dezimalkomma. Definiere zuerst die erwarteten Ergebnisse und diskutiere insbesondere, ob eine Datei ohne Daten erlaubt sein soll.

Isolierung, Stubs und echte Kopplung

Ein Stub ersetzt eine Abhängigkeit durch eine vorgegebene Antwort; ein Mock kann zusätzlich Interaktionen prüfen. Isoliere externe Systeme für schnelle Tests, aber ersetze in mindestens einem Integrationstest den echten CSV-Parser und die echte Wertfunktion nicht durch Mocks. Sonst bleibt ein Fehler im Zusammenspiel unentdeckt. Temporäre Dateien gehören in einen pro Test getrennten Bereich; echte Kundenordner sind tabu.

Den Nutzerpfad End-to-End ausführen

Lokale Importoberfläche als Kommandozeilen-App

Die Importoberfläche des Modellfalls ist bewusst eine lokale Kommandozeile. Vertrag: Der Aufruf `python app.py beispiel.csv` zeigt bei zwei gültigen Messwerten `2 Messwerte importiert` und beendet sich mit Rückgabecode 0. Bei ungültiger Datei zeigt er eine Meldung mit `Importfehler` und beendet sich mit Code 2. Das prüft einen durchgängigen Nutzerweg vom Dateipfad bis zur Rückmeldung. Kein Browser und kein Netz ist erforderlich.

Datei `app.py`:

import sys
from pathlib import Path
from importer import import_csv

def main():
    try:
        if len(sys.argv) != 2:
            raise ValueError("Genau ein Dateipfad erforderlich")
        text = Path(sys.argv[1]).read_text(encoding="utf-8")
        daten = import_csv(text)
        print(f"{len(daten)} Messwerte importiert")
        return 0
    except (ValueError, OSError, TypeError) as exc:
        print(f"Importfehler: {exc}", file=sys.stderr)
        return 2

if __name__ == "__main__":
    raise SystemExit(main())

Beachte: Das Beispiel fängt `TypeError` ab, um bei dem bekannten Importfehler keine rohe Fehlerspur im Nutzertext auszugeben. Das ersetzt nicht die Korrektur des Integrationsvertrags.

E2E mit temporärer Datei und subprocess

import subprocess
import sys
from pathlib import Path

def test_nutzerpfad_import(tmp_path):
    datei = tmp_path / "beispiel.csv"
    datei.write_text("zeit,wert\nT1,0\nT2,100\n",
                     encoding="utf-8")
    app = Path(__file__).resolve().parent / "app.py"
    result = subprocess.run(
        [sys.executable, str(app), str(datei)],
        capture_output=True, text=True, timeout=10
    )
    assert result.returncode == 0
    assert result.stdout.strip() == "2 Messwerte importiert"

def test_nutzerpfad_fehler(tmp_path):
    datei = tmp_path / "fehler.csv"
    datei.write_text("zeit,messwert\nT1,50\n", encoding="utf-8")
    app = Path(__file__).resolve().parent / "app.py"
    result = subprocess.run(
        [sys.executable, str(app), str(datei)],
        capture_output=True, text=True, timeout=10
    )
    assert result.returncode == 2
    assert "Importfehler" in result.stderr

Lege `app.py`, `messwerte.py`, `importer.py` und die Testdateien im gleichen Übungsverzeichnis ab. Der Pfad im Code setzt voraus, dass die E2E-Testdatei neben `app.py` liegt. Dokumentiere mindestens einen erfolgreichen und einen gezielt fehlerhaften echten Durchlauf mit Kommando, Umgebungsdaten und Ergebnis. Füge absichtlich einen Defekt ein und prüfe, dass mindestens ein Test rot wird. Niemals nur die Ausgaben erfinden oder ein grünes Protokoll abschreiben.

Optional: ein lokaler Browserpfad

Falls du später eine eigene lokale Weboberfläche ergänzt, kann Playwright sichtbare Felder befüllen, eine Importaktion auslösen und die Rückmeldung prüfen. Dies ist Vertiefung: ein Browser-Test ist ohne real vorhandene Weboberfläche nicht ausführbar. Verwende nur `localhost`, erfundene Daten und eigene Berechtigungen. Offizielle Python-Anleitung für Playwright erläutert Aktionen und Assertions. Automatische Wartefunktionen mindern, beseitigen aber nicht jeden instabilen Test.

Erklärvideo (Englisch): Andrew Knight, Python Web Conf 2022, Playwright und pytest für E2E-Tests; der Quellvideoeintrag ist öffentlich dokumentiert.

Video direkt öffnen. Textalternative: Der lokale E2E-Test oben bildet einen vollständigen Pfad ohne Video und Browser ab. YouTube-Unterstützung und Wiedergabe hängen vom Endgerät ab.

Automatisieren, prüfen und Verantwortung behalten

Reproduzierbarer Ablauf und Review

Ein verlässlicher Ablauf heißt: Änderungen in einem eigenen Git-Zweig, Abhängigkeiten nachvollziehbar installieren, `python -m pytest -q` tatsächlich starten, Fehlschläge untersuchen, Korrekturen erneut testen, Änderungen überprüfen und erst dann im Team zur Freigabe vorschlagen. Beispielhafte Dokumentation:

Geplant: acht Grenzwertfälle, drei Importfälle und zwei Nutzerpfade.
Ausgeführt: genaue Testanzahl und Ergebnis erst nach eigenem realem Lauf eintragen.
Nachweis: Python- und pytest-Version, Betriebssystem, Git-Commit, Testbefehl, Rückgabecode, gekürzte Fehlermeldung, verantwortliche prüfende Person.
Grenze: Grünes Ergebnis bedeutet nur, dass die geprüften Fälle im beobachteten Kontext bestanden sind; kein Beweis vollständiger Sicherheit.

Continuous Integration (CI) führt die Tests bei Änderungen automatisiert aus. Nutze lokal oder in einer schulisch genehmigten Testumgebung die gleichen Befehle. Sperre produktive Zugangsdaten, Schreibzugriffe auf fremde Repositories und automatische Freigaben. Ein fehlgeschlagener Sicherheits- oder Schnittstellentest darf nicht durch Löschung, `skip` oder niedrigere Grenzwerte versteckt werden.

Unabhängige Sollwerte und KI-Agenten

Ein KI-Agent kann Testideen oder Code vorschlagen, aber er darf weder seine eigenen Erwartungen ungeprüft zum Maßstab erklären noch eigenmächtig produktive Rechte ausweiten. Richte die Rechte nach Minimalprinzip ein: Übungsordner lesen und lokal schreiben; keine Geheimnisse, keine fremden Systeme, kein unbeaufsichtigter Merge. Tests werden durch tatsächlich ausgeführte Kommandos nachgewiesen. Menschliche Reviewentscheidungen beurteilen fachliche Sollwerte, Fehlerbehebung und Freigabe getrennt. Die MCP-Sicherheitsempfehlungen, Dokumentationspfad 2026-07-28 befassen sich mit Risiken wie übermäßigen Berechtigungen und unsicheren Autorisierungsflüssen; sie sind keine Testzertifizierung. Das NIST Generative-AI-Profil AI 600-1, Juli 2024 behandelt KI-Risikomanagement. Es ist ein ergänzender Sicherheitsrahmen und kein spezifischer Python-Teststandard.

Fehlerfall begründet entscheiden und transferieren

Prüfkriterium A – Unit-Grenzfall: Der Wert 100 muss angenommen, 100.01 muss zurückgewiesen werden. Zeige Eingabe, vorab definierten Sollwert und echten Testausgang. Prüfkriterium B – Schnittstellenfehler: Eine Zeile mit fehlender `wert`-Zelle muss gemäß Vertrag `ValueError` erzeugen; im Ausgangsstand ist genau dies fehlerhaft. Erkläre, warum die richtige Reparatur an der Übergabe liegt. Prüfkriterium C – Nutzerpfad: Starte `app.py` mit gültiger und ungültiger CSV per `subprocess`; prüfe Text und Rückgabecode. Dokumentiere, welche Funktion jede Ebene absichert und welcher Defekt trotz grüner Tests noch möglich bleibt.

Transfer: Eine neue Vorgabe fordert Werte bis 120. Erstelle zunächst neue unabhängige Grenzsollwerte, passe danach Implementierung und Tests an. Diskutiere, warum alte Tests nicht kommentarlos gelöscht werden dürfen. Verwende keine Maschinenfreigabe, keine Echtzeitmessung und keine ungeprüfte Automationsfreigabe.

Interaktive Aufgaben

Multiple-Choice: Tests und Entscheidungen

Wähle die am besten begründete Aussage. Du erhältst Hinweise zur Selbstkontrolle; die korrekte Option steht in der interaktiven Darstellung erst bei der Auswertung fest.

1. Welche Aussage beschreibt einen Unit-Test für parse_value am besten? (Ein isolierter Test der Funktion mit festem Eingabewert und unabhängigem Sollwert) (!Ein Test über den vollständigen Browser und Server) (!Eine Prüfung nur mit produktiven Messdaten) (!Ein Test der Anzahl der Quellcodezeilen)

Hinweis zur Selbstkorrektur: Vergleiche eine einzelne Funktion mit einem vorab festgelegten erwarteten Ergebnis.

2. Welche Grenzwerte sollen beim erlaubten Messbereich von null bis hundert akzeptiert werden? (Null und hundert als inklusive Grenzen) (!Nur Werte strikt zwischen null und hundert) (!Alle negativen Werte) (!Auch unendliche Gleitkommazahlen)

Hinweis zur Selbstkorrektur: Prüfe die vereinbarte inklusive Grenze und ergänze knapp außerhalb liegende Gegenbeispiele.

3. Warum muss parse_value den Wert nan zurückweisen? (Weil nan kein endlicher Messwert ist und Vergleiche irreführend werden können) (!Weil nan automatisch null bedeutet) (!Weil nan eine gültige Zeitangabe ist) (!Weil Python alle Buchstaben verbietet)

Hinweis zur Selbstkorrektur: Prüfe ausdrücklich Endlichkeit zusätzlich zum Bereich.

4. Was prüft ein Integrationstest von import_csv besonders? (Das Zusammenspiel von CSV Parser Kopfzeile und Wertvalidierung) (!Nur die Schriftgröße des Dateinamens) (!Nur die CPU Auslastung) (!Die Lizenz der Python Installation)

Hinweis zur Selbstkorrektur: Betrachte die verknüpften Komponenten und die vertraglich definierten Fehlermeldungen.

5. Welche Eingabe deckt einen konkreten Schnittstellenfehler ab? (Eine CSV Datei mit der falschen Spalte messwert statt wert) (!Ein gültiger Wert genau fünfzig) (!Eine korrekte Datei mit zwei Zeilen) (!Ein isolierter Aufruf mit dem Wert null)

Hinweis zur Selbstkorrektur: Ein Schnittstellentest braucht auch negative Fälle an der Übergabestelle.

6. Woran erkennt man einen echten End-to-End-Test der lokalen App? (Ein Test startet die App über die Nutzerschnittstelle und prüft Ausgabe und Rückgabecode) (!Ein Test vergleicht nur zwei Konstanten) (!Ein Test liest ausschließlich den Funktionsnamen) (!Ein Test behauptet ohne Start dass alles funktioniert)

Hinweis zur Selbstkorrektur: Der Test muss den vereinbarten Nutzerpfad tatsächlich durchlaufen.

7. Was ist ein unabhängiges Testorakel? (Ein vor der Implementierung fachlich festgelegter Sollwert) (!Eine Kopie derselben fehlerhaften Berechnungsfunktion) (!Die zuletzt erhaltene Programmausgabe) (!Ein automatisch erfundener zufälliger Wert)

Hinweis zur Selbstkorrektur: Erwartungswerte dürfen nicht aus der zu prüfenden Logik selbst abgeleitet sein.

8. Welche Maßnahme macht Testläufe reproduzierbarer? (Feste Testdaten isolierte temporäre Dateien und dokumentierte Abhängigkeiten) (!Zufällig wechselnde echte Kundendaten) (!Schreibrechte auf alle produktiven Systeme) (!Automatisches Überspringen fehlgeschlagener Tests)

Hinweis zur Selbstkorrektur: Stabile Startbedingungen reduzieren ungewollte Unterschiede.

9. Wann darf eine KI einen fehlgeschlagenen Test eigenständig als bestanden umdeuten? (Nie denn die Freigabe folgt den vereinbarten Regeln und menschlichem Review) (!Immer wenn der Code neu ist) (!Wenn ein Fehler nur einmal auftritt) (!Wenn der Agent dieselben Tests geschrieben hat)

Hinweis zur Selbstkorrektur: Ein Testbericht ist ein überprüfbares Ergebnis und keine Freigabeentscheidung des Agenten.

10. Welche Aussage trifft zur Testpyramide am ehesten zu? (Viele schnelle Unit-Tests werden durch gezielte Integrations- und wenige E2E-Tests ergänzt) (!Nur End-to-End-Tests sind sinnvoll) (!Jeder Unit-Test ersetzt den Review) (!Eine Pyramide garantiert Fehlerfreiheit)

Hinweis zur Selbstkorrektur: Die Verteilung ist eine Orientierung und muss an Risiko und Anwendung angepasst werden.

Memory: Fachbegriffe verbinden

Ordne jeden Begriff seiner passenden, einmalig verwendeten Erklärung zu.

Unit-Test	Prüft eine einzelne kleine Codeeinheit möglichst isoliert
Integrationstest	Überprüft das Zusammenwirken von CSV-Leser und Wertprüfung
End-to-End-Test	Durchläuft den gesamten vereinbarten Nutzerpfad
Testorakel	Vor der Ausführung fachlich bestimmtes Sollverhalten
Fixture	Baut reproduzierbare Startbedingungen für einen Test auf
Regression	Früher funktionierendes Verhalten wird durch Änderung gestört

Drag-and-Drop: Testbeleg zuordnen

Verbinde die jeweils passende Tätigkeit mit ihrem Nachweis.

Gesuchte Tätigkeit	Passender Nachweis
Grenzwerte festlegen	Vertrag mit null und hundert als gültigen Randwerten
Funktionsverhalten prüfen	Assertion für parse_value mit festen Beispielen
Schnittstelle provozieren	Import mit fehlender Wertespalte
Anwendung ausführen	subprocess mit Rückgabecode und Ausgabe
Review dokumentieren	Änderungsprotokoll mit Testlauf und menschlicher Freigabeentscheidung

Kreuzworträtsel

Trage jeweils ein einzelnes Fachwort ein.

Grenze	Welche Stelle zwischen erlaubtem und unerlaubtem Zahlenbereich verlangt besondere Tests?
Assertion	Wie heißt die programmatische Behauptung über ein erwartetes Testergebnis?
Import	Wie nennt man das Einlesen externer Daten in eine Anwendung?
Fixture	Welcher pytest Begriff bezeichnet eine vorbereitete Testumgebung?
Regression	Wie heißt das erneute Auftreten eines bereits behobenen Fehlers nach einer Änderung?
Review	Wie heißt die prüfende Begutachtung einer Codeänderung durch eine verantwortliche Person?

LearningApps

Erkunde zusätzlich passende Zuordnungs- und Lückentextübungen über die LearningApps-Themensuche. Die Suche bietet keine Garantie, dass ein bestimmtes fremdes Lernspiel verfügbar oder fachlich überprüft ist. Bearbeite zuerst die lokalen Übungen dieses aiMOOC.

Lückentext: vom Vertrag zum Testlauf

Eine kleine isolierte Funktion wird typischerweise durch einen

geprüft.

Das Zusammenspiel des CSV-Lesers und der Werteprüfung untersucht ein

.

Den vollständigen Weg von einer Beispieldatei bis zur Konsolenausgabe prüft ein

.

Ein vorab fachlich vereinbarter Erwartungswert ist ein

.

Die erwartete Python-Ausnahme bei falschen Messdaten heißt

.

Nicht endliche Zahlen werden mithilfe von math.isfinite als

erkannt.

Ein tatsächlicher Testlauf muss seine beobachteten

dokumentieren.

Die Prüfung und Freigabe von Codeänderungen erfordert ein menschliches

.

Offene Aufgaben

Leicht

Grenzwerttabelle: Notiere für 0, 100, -0.01 und 100.01 unabhängige Sollwerte, ohne den Produktionscode zu kopieren.
Drei Testebenen: Zeichne ein Textschema für Unit, Integration und E2E am Beispiel der Messdaten-App.
Fehlertext verstehen: Erkläre an einem erfundenen Beispiel den Unterschied zwischen `ValueError` und einem unerwarteten `TypeError`.
Testlauf protokollieren: Führe lokal einen vorgegebenen pytest-Aufruf aus und notiere Version, Befehl und Ergebnis; falls die Software fehlt, dokumentiere den Grund ohne ein Ergebnis zu erfinden.

Standard

Unit-Suite ergänzen: Implementiere einen parametrisierten Test für `nan`, `inf`, 50.25 und einen leeren Text.
Importfehler reproduzieren: Zeige den Unterschied zwischen erwartetem `ValueError` und tatsächlich ausgelöstem `TypeError` bei fehlendem CSV-Wert.
Kommandozeilenpfad prüfen: Baue zwei temporäre CSV-Dateien und teste Ausgabe und Exitcode des lokalen CLI-Programms.
Faktenblatt anfertigen: Verfasse ein kurzes Prüfreport mit drei Risiken, echten Testbefehlen und einer menschlichen Reviewentscheidung.

Schwer

Neue Fachanforderung: Ändere den gültigen Wertebereich nach schriftlich bestätigtem Auftrag auf 0 bis 120 und zeige vorher rot und nachher grün.
Mutationsexperiment: Ersetze testweise die obere Schranke durch 99.99, dokumentiere den entdeckenden Test und stelle den Originalcode wieder her.
Berechtigungsgrenzen: Entwerfe eine Matrix für Testperson, KI-Agent und Reviewer mit erlaubten und gesperrten Datei- und Freigabeaktionen.
Transferlösung: Ergänze optional eine nur lokale Weboberfläche und schreibe einen Playwright-Test; wenn keine Browserumgebung vorliegt, liefere ein ausführbares Testdesign und kennzeichne es ausdrücklich als nicht ausgeführt.

Lernkontrolle

Grenzfall: Stelle Testfall, Sollwert und beobachtetes Ergebnis für 100 und 100.01 gegenüber und begründe beide Entscheidungen.
Fehlerursache: Erkläre, weshalb die fehlende CSV-Zelle im ersten Implementierungsstand den falschen Ausnahmetyp liefert, und demonstriere die korrigierte Stelle.
Nutzerpfad: Weise mit zwei echten `subprocess`-Läufen nach, dass Erfolg und Fehler über Rückgabecode und Text erkennbar sind.
Testauswahl: Begründe, welche drei Risiken Unit-, Integrations- beziehungsweise E2E-Tests abdecken und welche Risiken unbelegt bleiben.
Unabhängigkeit: Vergleiche einen selbst festgelegten Sollwert mit einem aus dem Code abgeleiteten und beurteile die Aussagekraft.
Reviewgrenze: Entscheide für einen fehlgeschlagenen CI-Test, ob der Agent freigeben, korrigieren oder eskalieren darf, und begründe den Umfang seiner Rechte.

Lernnachweis

Abgabeprodukt: Ein Git-Ordner mit `messwerte.py`, `importer.py`, `app.py`, mehreren `test_*.py`-Dateien, synthetischen CSV-Dateien und `README.md`. Die README enthält fachliche Sollwerte, Startanleitung ohne kostenpflichtige Konten, Python- und pytest-Version, echte ausgeführte Kommandos, Ergebnisse, bekannte Einschränkungen und die Erklärung einer menschlichen Reviewentscheidung.

Nachweiskriterien: (1) Grenzfall null/hundert und knapp außerhalb unabhängig begründet; (2) Schnittstellenfehler zuerst reproduziert und anschließend nachweisbar korrigiert; (3) kompletter Nutzerpfad im realen lokalen Prozess einmal positiv und einmal negativ getestet. Bewertung: Fachvertrag und Sollwerte 25 Prozent, nachvollziehbare Unit-Tests 20 Prozent, Importtests mit Fehlerbegründung 20 Prozent, ausgeführte E2E-Tests 20 Prozent, Bericht und Rechte-/Reviewkonzept 15 Prozent. Hilfen: Arbeite zuerst mit den gezeigten Dateien, dann mit einer Checkliste der Fachverträge. Vertiefung: Erweitere Zeitstempelvalidierung und negative Sicherheitstests ausschließlich in der Simulation.

Ehrliche Grenzen: Der Kurs liefert überprüfbare Beispiele und Aufforderungen zum Ausführen, aber keinen fingierten grünen Testbericht. Der Lernnachweis ist erst vollständig, wenn echte lokale Testläufe protokolliert sind. Prüfwerte und Beispiele sind synthetisch. Keine reale Maschinensteuerung und keine Sicherheitsfreigabe.

OER und Wikipedia

Fachquellen und Recherchestand: überprüfte öffentliche Einstiegsseiten am 22.10.2026; Dokumentationen können sich später ändern.

pytest: Get Started, offizielle laufende Dokumentation, online ohne feste Versionszusage; maßgeblich ist deine lokal dokumentierte Paketversion.
pytest: Parametrisierung, offizielle Anleitung zu mehreren Testeingaben.
Playwright Python: Writing tests, offizielle laufende Dokumentation; kein Ersatz für den lokalen ausführbaren CLI-Test.
Model Context Protocol: Security Best Practices, versionierter Dokumentationspfad 2026-07-28; ergänzende Sicherheitsquelle.
NIST AI 600-1: Generative Artificial Intelligence Profile, Veröffentlichung Juli 2024; Risiko-Orientierung, keine Python-Testvorgabe.
Wikipedia: Softwaretest, deutschsprachiger Überblick; Angaben kritisch mit Originaldokumentation abgleichen.
Wikipedia: Modultest, ergänzender Überblick.
Vorhandene MOOCwiki-Grundlage, vom Auftrag vorgegebener Bezug; Detailinhalt beim Abruf nicht verifiziert.

Medienquellen und Lizenznachweise:

Medium	Originalseite	Urheber	Lizenz oder Nutzungsstatus
File:Testing Pyramid.svg	Wikimedia Commons	Abbe98	CC BY-SA 4.0
File:Software test methods.svg	Wikimedia Commons	Marekventur	CC BY-SA 3.0
File:Testgetriebener Entwicklungsprozess.svg	Wikimedia Commons	MovGP0	Vom Urheber freigegebene Weiterverwendung
https://www.youtube.com/watch?v=YbpKMIUjvK8	Videoeintrag	pixegami	YouTube-Vorführung, keine OER-Lizenz behauptet
https://www.youtube.com/watch?v=tKKMPuOsh0U	Videoeintrag	Andrew Knight / Six Feet Up	YouTube-Vorführung, keine OER-Lizenz behauptet

Bildvorschaubilder und Alternativen: In den drei Bildabschnitten stehen beschreibende Alttexte und vollständige Textalternativen. Für die Videos gibt es direkt darunter Text- und Codealternativen. Es werden keine externen Medien kopiert oder neu produziert. Die genaue spätere Abrufbarkeit fremder Videos ist nicht garantiert.