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

Testgetriebene Softwareentwicklung mit KI-Agenten

QR-Code

Einleitung

Du entwickelst eine kleine Messdaten-App mit synthetischen Beispieldaten weiter. In diesem Kurs lernst du, Anforderungen zuerst als überprüfbare Tests zu beschreiben, dann nur die notwendige Funktion zu ändern und anschließend bestehende Funktionen erneut zu prüfen. Ein KI-Agent darf Änderungsvorschläge liefern, aber die Anforderungen, Rechte, Abnahme und Freigabe bleiben bei Menschen. Lernprodukt ist eine dokumentierte TDD-Änderung an einer Grenzwertprüfung.

Zielgruppe: Auszubildende im 2. bis 3. Ausbildungsjahr. Voraussetzungen: A1 oder Grundlagen in Python, Dateien, Git und einfachen Softwaretests. Zeitbedarf: etwa 4 bis 6 Unterrichtseinheiten einschließlich Lernnachweis. Ohne Bezahlkonto: Alle Kernaufgaben funktionieren lokal mit Python und der Standardbibliothek unittest. Eine KI kann durch vorbereitete Agentenvorschläge simuliert werden.

Anschluss an den Vorkurs: Vorhandene MOOCwiki-Grundlage (Seiten-ID 60543). Wiederhole dort bei Bedarf Dateistrukturen, Git und Testaufrufe. Die konkrete Seite war beim Quellencheck nicht abrufbar; ihr genauer Inhalt wird deshalb nicht behauptet.

Sicherheitsrahmen: Nur simulierte Messwerte und lokale Dateien. Keine reale Maschinensteuerung, keine Sicherheitsfreigabe, keine echten Betriebs- oder Schülerdaten. Dieses unabhängige Bildungsangebot ist weder eine offizielle Liebherr-Schulung noch eine IHK-Zertifizierung.

Anforderungen vor Code: der TDD-Gedanke

Test zuerst – Red, Green, Refactor

Testgetriebene Entwicklung (Test-driven Development, TDD) beginnt mit einer beobachtbaren Anforderung. Du schreibst zuerst einen Test, der für die noch fehlende Funktion aus dem richtigen Grund scheitert (Red). Dann ergänzt du gerade genug Produktivcode, damit er besteht (Green). Erst bei grünem Testlauf verbesserst du bei Bedarf die interne Struktur ohne das geforderte Verhalten zu verändern (Refactor).

Bildbeschreibung: Das englischsprachige Diagramm zeigt den wiederholten Zyklus von Test und Implementierung. Ohne Bild: Anforderung → neuer Test schlägt erwartungsgemäß fehl → kleinste Änderung → alle Tests bestehen → optional aufräumen → erneut testen.

Warum Anforderungen spiegeln statt Implementierungen? Ein Test soll beantworten, was bei einer Eingabe laut Fachanforderung herauskommt – nicht, ob ein bestimmter Codezweig oder Funktionsname existiert. Beispiel: „81 ist bei Grenzwert 80 oberhalb“ ist eine Verhaltensaussage. „Die Funktion muss eine if-Abfrage benutzen“ wäre nur eine Implementierungsvorgabe. Diese Unterscheidung schützt vor Tests, die Fehler bloß nachprogrammieren.

Drei überprüfbare Qualitätskriterien

Kriterium	Sichtbarer Nachweis	Gegenbeispiel
Rot zuerst	Ein neuer, sinnvoller Test scheitert am fehlenden Verhalten, dokumentiert mit Fehlermeldung.	Er scheitert nur wegen eines Tippfehlers im Import.
Minimale Änderung	Ausschließlich die zur Anforderung gehörende Fallunterscheidung wird ergänzt.	Ein Agent baut nebenbei Datenbank und Benutzerverwaltung um.
Regression grün	Neuer und vorhandene Tests bestehen nach der Änderung gemeinsam.	Nur der neue Test wird isoliert ausgeführt.

Begriffe: Eine Assertion vergleicht erwartetes mit beobachtetem Ergebnis. Ein Grenzfall liegt unmittelbar am Übergang, zum Beispiel 80 oder 81. Ein Regressionstest prüft, dass zuvor funktionierendes Verhalten durch eine Änderung nicht kaputtging.

Vertiefung: Warum ein grüner Test nicht alles beweist

Tests prüfen nur ausgewählte Beispiele. Ein fehlerhaft formulierter Test kann grün werden, obwohl die Anforderung verletzt ist. Entscheidend sind nachvollziehbare Fachregeln, Eingabevalidierung, positive und negative Fälle sowie der Blick auf die Grenzen einer Testabdeckung. Bei Messwerten müssen Einheiten, Genauigkeit, fehlende Werte und der Unterschied zwischen größer als und größer oder gleich bewusst festgelegt werden.

Video (Deutsch): the native web GmbH, Testen mit TDD: Eine Einführung in 100 Minuten (2022). Besonders relevant sind die Abschnitte über den ersten roten Test, die minimale Implementierung und Refactoring. Ohne Video: Lies die obige Definition und zeichne drei Kästen „Rot“, „Grün“ und „Aufräumen“ mit Prüfnachweisen.

Fachanforderungen in ausführbare Tests übersetzen

Fachliche Regel für die Messdaten-App

Die erfundene App bekommt simulierte Temperaturwerte als Zahlen. Anforderung G1: Bei Grenzwert 80 bedeutet ein Messwert bis einschließlich 80 „ok“; erst ein Wert größer als 80 liefert „ueber“. Das ist eine reine Textkennzeichnung, kein Alarm und kein Steuerbefehl. Anforderung G2: Negative Werte sind in diesem vereinfachten Modell ungültig und sollen mit ValueError abgewiesen werden. In echten Systemen können negative Temperaturen selbstverständlich sinnvoll sein; G2 ist nur eine ausdrücklich vereinbarte Übungsregel.

Eine gute Akzeptanzbeschreibung enthält Eingabe, erwartetes Ergebnis und einen Grenzfall. Beispiele: (50, 80) → „ok“; (80, 80) → „ok“; (81, 80) → „ueber“. Ergänze einen Eingabefehler und erkläre, warum gerade dieser Test zur Fachregel gehört.

Arrange, Act, Assert und lesbare Fehlersignale

Teile die Prüfung gedanklich in drei Teile: Arrange bereitet Werte vor, Act ruft die Funktion auf, Assert vergleicht das Resultat. Die Python-Standardbibliothek unittest kann das offline erledigen. Mit pytest geht es ebenfalls, falls es bereits installiert ist; ein zusätzliches KI-Konto ist nicht nötig.

# test_messwerte.py – zunächst vollständig anlegen
import unittest
from messwerte import bewerte_wert

class TestGrenzwert(unittest.TestCase):
    def test_normal(self):
        self.assertEqual(bewerte_wert(50), "ok")

    def test_genau_am_limit(self):
        self.assertEqual(bewerte_wert(80), "ok")

    def test_oberhalb(self):
        self.assertEqual(bewerte_wert(81), "ueber")

if __name__ == "__main__":
    unittest.main()

Beobachtung statt Geheimlösung: Die letzte Assertion prüft das neu verlangte Verhalten. Die zwei ersten bilden die Rückversicherung. Ein fachlich guter Test nennt konkrete Eingaben und Ergebnisse; er schreibt keine bestimmte if-Anweisung vor.

Importprüfung als nächster Entwicklungsauftrag

Die spätere Datei werte.csv enthält ausschließlich synthetische Zeilen:

id;wert
M01;50
M02;80
M03;81

Formuliere vor dem Parser fachliche Importtests: korrekte Spaltennamen und Trennzeichen, zulässige Zahlen, Leerdatei und fehlerhafte Zahl wie „achtzig“. Ein Importfehler muss einen verständlichen Hinweis erzeugen statt still einen Ersatzmesswert zu erfinden. Vorhandene Grenzwerttests dürfen durch neue Importfunktionen nicht verändert werden. Nutze zunächst Texte im Arbeitsspeicher, keine fremden Dateien.

Geführtes Praxisbeispiel: Rot, minimale Änderung, Regression

Ausgangspunkt und roter Test

Lege in einem leeren lokalen Übungsordner messwerte.py und test_messwerte.py an. Die Ausgangsfunktion bewahrt die beiden bekannten Fälle, kennt aber noch keine Überschreitung:

# messwerte.py – Ausgangsversion
def bewerte_wert(wert, grenze=80):
    return "ok"

Führe im Projektordner python -m unittest -v aus; je nach System heißt der Befehl python3 -m unittest -v. Erwartung: test_normal und test_genau_am_limit sind grün; test_oberhalb schlägt als AssertionError fehl, weil „ok“ statt „ueber“ zurückkommt. Die Namen und Zählwerte hängen von der Testumgebung ab; relevant ist die Ursache, nicht die exakte Textform der Konsolenausgabe.

Prüfnachweis Rot: Schreibe „test_oberhalb: erwartet ueber, erhalten ok“. Wäre stattdessen das Python-Modul nicht auffindbar, musst du erst das Setup reparieren; das wäre noch kein guter TDD-Nachweis.

Kleinste Implementierung

Erst nach dem dokumentierten roten Test änderst du nur die Produktivfunktion:

# messwerte.py – minimale Änderung für G1
def bewerte_wert(wert, grenze=80):
    if wert > grenze:
        return "ueber"
    return "ok"

Prüfe die drei Beispiele gedanklich: 50 und 80 bleiben „ok“; 81 wird „ueber“. Keine Änderung an Testwerten, keine Erweiterung anderer Dateien, keine zusätzliche Benutzeroberfläche. Der Änderungssatz ist minimal, weil er ausschließlich das neue Verhalten abbildet.

Alle Tests grün und Refactoring

Rufe erneut python -m unittest -v auf. Erwartung: alle drei Tests bestehen. Das ist der Regression-nach-Green-Nachweis. Sichere eine kurze Änderungsnotiz: Regel G1, vorherige Fehlermeldung, betroffene Funktion, vollständiges Testergebnis. Ist der Code bereits klar, musst du kein unnötiges Refactoring durchführen.

Bildbeschreibung: Mehrere kleine Zyklen bilden eine fortlaufende Entwicklung. Ohne Bild: Nach jedem grünen Durchlauf beginnt für die nächste neue Anforderung wieder ein roter Test.

Begründeter Fehlerfall als zweite Runde

Nun folgt G2, negative Werte zurückweisen. Schreibe erst einen zusätzlichen Test und führe alle Tests aus:

def test_negativer_wert(self):
    with self.assertRaises(ValueError):
        bewerte_wert(-1)

Füge diese Methode innerhalb der Klasse TestGrenzwert ein. Sie ist zunächst rot, weil die Funktion für -1 „ok“ liefert und keinen Fehler auslöst. Erst jetzt ergänze am Funktionsanfang:

if wert < 0:
    raise ValueError("Negativer Uebungswert")

Führe erneut alle Tests aus und erläutere, weshalb ein still akzeptiertes -1 in diesem vereinbarten Modell ein Fehler wäre. Für eine reale Anwendung wäre die Fachregel zu negativen Temperaturen zuerst neu zu prüfen.

KI-Agenten kontrolliert an TDD beteiligen

Entwicklungsauftrag mit prüfbaren Grenzen

Ein Coding-Agent ist ein Programm, das aus Anweisungen Änderungen und Testläufe vorschlägt oder – wenn ausdrücklich berechtigt – ausführt. Ein Agent ist keine unabhängige fachliche Prüfstelle. Formuliere den Auftrag wie ein überprüfbares Ticket:

Auftrag: „In der lokalen Beispiel-App soll ein Wert oberhalb von 80 mit ueber gekennzeichnet werden. Erstelle zuerst den neuen Verhaltenstest und zeige den erwarteten AssertionError. Ändere danach nur messwerte.py minimal. Führe die vollständige Testsuite aus. Melde geänderte Dateien, Diff und Testergebnisse. Keine Netzwerkanfragen, keine geheimen Daten, keine Änderungen außerhalb des Übungsordners, keine Veröffentlichung.“

Abnahmekriterien: Nachweis Rot vor Codeänderung, minimale Diff-Prüfung, alle bestehenden und neuen Tests grün, keine Änderung an Test-Erwartungen zur Ergebnisbeschönigung. Die menschliche Fachprüfung bewertet vor allem die Unterscheidung zwischen größer und größer oder gleich.

Rechte, Review und menschliche Freigabe

Nutze das Prinzip der geringsten Berechtigung: Der Agent darf nur die für den Auftrag nötigen Übungsdateien lesen; Schreibrechte gelten nur für einen eigenen Arbeitszweig oder begrenzten Ordner. Gehe bei unbekannten Werkzeugen von keiner zusätzlichen Berechtigung aus. Verweigere Zugriff auf echte Messsysteme, Zugangsdaten, Konten, Produktionskonfiguration, Deployment und den Hauptzweig. Ein menschlicher Reviewer kontrolliert die Dateiliste und jede fachliche Abweichung. Auch ein grüner Testlauf ersetzt weder Freigabe noch Sicherheitsnachweis.

Bildbeschreibung: Das Logo verweist auf nachvollziehbare Versionsstände. Ohne Bild: Prüfe in Git die geänderten Dateien und den Diff vor dem menschlich genehmigten Merge.

Agent-Simulation ohne KI: Eine Person übernimmt die Rolle „Agent“ und schlägt einen Patch vor; eine andere spielt den Reviewer. Alternativ vergleiche zwei vorbereitete Vorschläge: A fügt nur die eine Fallunterscheidung hinzu, B ändert zusätzlich Tests und deaktiviert die Prüfung für den Grenzfall. Verwerfe B, auch wenn dessen Testlauf grün erscheint.

Fehlerarten unterscheiden

Situation	Aussage	Sichere Folgerung
Roter AssertionError zu 81	Erwartetes Verhalten fehlt.	Minimalen Produktivcode ergänzen.
Roter ImportError	Testumgebung oder Modulpfad fehlerhaft.	Setup reparieren, noch kein Verhaltensnachweis.
Grüner Test nach Änderung der erwarteten Ausgabe auf „ok“	Test wurde passend zum Fehler verbogen.	Anforderung gegenlesen und Test korrigieren.
Nur neuer Test grün, alter Test rot	Regression.	Änderung nicht abnehmen.
Alle Tests grün, Agent fordert Schreibrecht für Produktion	Unzulässige Rechteausweitung.	Rechte verweigern und menschlich prüfen.

Die MCP-Sicherheitsleitlinien behandeln unter anderem Berechtigungsgrenzen und die Gefahr missbrauchter Autorisierung. Das NIST-Profil zu generativer KI dient als freiwilliger Rahmen für Risikobetrachtung, Nachvollziehbarkeit und menschliche Verantwortlichkeit. Beide ersetzen keine technische Sicherheitsprüfung.

Video (Englisch): Matt Pocock, Beitrag zu TDD mit Coding-Agenten (23.02.2026). Ohne Video: Lies den vorstehenden Auftrag und markiere darin die Test-, Datei-, Netzwerk- und Freigabegrenzen. Das Video illustriert einen Workflow, nicht die Verlässlichkeit eines bestimmten Agenten.

Transfer: selbstständig eine sichere Änderung nachweisen

Fallstudie Import und Grenzwerte

Du erhältst die drei synthetischen Datensätze M01=50, M02=80, M03=81. Plane getrennte Tests für Import und Bewertung. Ergänze zwei fehlerhafte CSV-Zeilen: etwa M04=abc und einen fehlenden Wert. Definiere ausdrücklich, ob bei einem Fehler die gesamte Datei oder nur eine Zeile abgewiesen wird. Ohne eine solche Entscheidung ist ein Test nicht eindeutig.

Diagramm aus der Softwaretest-Praxis, das die Abfolge wiederholbarer Regressionstests verdeutlicht

Bildbeschreibung: Die Grafik verdeutlicht die Wiederholung standardisierter Prüfungen. Ohne Bild: Notiere für jede Änderung alten Sollzustand, neuen Test und vollständigen Regressionstestlauf.

Prüfprotokoll für das Lernprodukt

Prüffeld	Dein Nachweis
Regel	Bei Grenzwert 80 ist 80 „ok“, 81 „ueber“.
Rot	Vorher fehlschlagender neuer Verhaltenstest mit Fehlerursache.
Minimale Änderung	Diff zeigt nur nötige Funktionserweiterung.
Regression grün	Gesamte lokale Testsuite bestanden.
Fehlerbegründung	Negativer Übungswert oder fehlerhafte CSV-Zeile fachlich erklärt.
Rechte und Review	Kein Produktionszugriff; menschliche Abnahme mit Begründung.

Vertiefung: Nutze zusätzlich eine datengesteuerte Tabelle mit Werten knapp unter, exakt auf und knapp über einer fachlich gewählten Grenze. Diskutiere Dezimalwerte und den Umgang mit NaN, falls das Zahlenmodell solche Werte erlauben soll. Ein grüner Beispieltest ist kein Beweis für Vollständigkeit oder Sicherheit.

Interaktive Aufgaben

Bearbeitungshinweis: Beantworte zunächst ohne den Code zu verändern. Die Auswertung erfolgt innerhalb der Quizaufgaben. Begründungen lassen sich aus den Fachkapiteln ableiten; die Lösungen werden nicht als vorgeschaltete Liste gezeigt.

Quiz: Teste dein Wissen

Woran erkennst du den ersten gültigen roten TDD-Schritt für G1? (Der Test zu Wert 81 meldet eine fachlich falsche Rückgabe) (!Ein Dateiname wurde falsch geschrieben) (!Die Python-Installation ist nicht vorhanden) (!Der Test wurde ohne Ausführung als rot markiert)

Welche Aussage legt die Grenze 80 eindeutig fest? (Erst Werte über 80 werden als ueber bewertet) (!Bereits 80 wird als ueber bewertet) (!Jeder positive Wert wird als ueber bewertet) (!Die Grenzzahl wird vom Agenten zufällig gewählt)

Was ist nach einem erwarteten roten Verhaltenstest der passende Schritt? (Die kleinste nötige Produktivcodeänderung vornehmen) (!Alle bestehenden Tests löschen) (!Einen Produktionsserver anbinden) (!Die erwartete Testausgabe an den Fehler anpassen)

Welcher Nachweis belegt Regression grün? (Neue und bestehende Tests bestehen im vollständigen Lauf) (!Nur der neue Test wurde aufgerufen) (!Der Code sieht für einen Agenten plausibel aus) (!Die Testdatei wurde aus der Versionsverwaltung entfernt)

Was ist ein fachlicher Grenzfall zu Schwelle 80? (Der Messwert 80 selbst) (!Eine beliebige neue Ordnerbezeichnung) (!Eine nicht installierte Entwicklungsumgebung) (!Der Name der verwendeten Programmiersprache)

Wie reagierst du auf einen ImportError im neuen Test? (Zuerst Pfad oder Importkonfiguration prüfen) (!Sofort von einer gelungenen Red-Phase sprechen) (!Die Fachanforderung verwerfen) (!Dem Agenten alle Systemrechte erteilen)

Was ist im Übungsmodell die erwartete Behandlung von minus eins? (Eine ValueError Ausnahme) (!Ungeprüft als ok ausgeben) (!Die lokale Festplatte löschen) (!Einen echten Maschinenstopp auslösen)

Welche Agentenberechtigung ist für diesen Auftrag angemessen? (Begrenzter Zugriff auf Übungsdateien ohne Produktionsrechte) (!Uneingeschränkter Zugriff auf alle Konten) (!Automatisches Deployment ohne Review) (!Lesen privater Zugangsdaten für den Grenzwerttest)

Warum ist ein unveränderter Verhaltenstest für die Abnahme wichtig? (Er bewahrt die unabhängig formulierte Erwartung der Fachregel) (!Er zwingt den Agenten zur Verwendung einer bestimmten Schleife) (!Er ersetzt die Prüfung aller anderen Tests) (!Er garantiert die Fehlerfreiheit des gesamten Systems)

Wann darf eine simulierte Änderung fachlich abgenommen werden? (Nach geprüftem Diff vollständigem grünen Testlauf und menschlichem Review) (!Sobald der Agent erfolgreich meldet) (!Sobald nur ein ausgewählter Test grün wird) (!Sobald Zugriff auf Produktionsgeräte eingerichtet ist)

Memory

Ordne Fachbegriff und Bedeutung zu.

Red-Phase	Neuer Test schlägt aus dem erwarteten fachlichen Grund fehl
Green-Phase	Kleinste Produktivänderung bringt Tests zum Bestehen
Refactoring	Interne Struktur ohne geändertes Sollverhalten verbessern
Regressionstest	Früher funktionierendes Verhalten erneut prüfen
Assertion	Beobachtetes Ergebnis mit erwarteter Aussage vergleichen
Reviewer	Änderung und fachliche Abnahme unabhängig kontrollieren

Drag-and-Drop

Ordne die Schritte den passenden Beobachtungen zu.

Passenden Begriff zuordnen	Beobachtung aus dem Entwicklungsablauf
Fachregel	Eingabe 81 bei Grenze 80 soll ueber ergeben
Roter Nachweis	Assertion meldet vor Änderung ok statt ueber
Minimale Implementierung	Ausschließlich neue Fallunterscheidung in der Funktion
Gesamtlauf	Alle bisherigen und neuen Prüfungen werden ausgeführt
Reviewfreigabe	Mensch kontrolliert Diff Rechte und Begründung

Kreuzworträtsel

Trage die gesuchten Fachwörter ein.

Grenze	Welcher Schwellenwert trennt im Modell die Bereiche?
Regression	Wie heißt eine unerwünschte Rückkehr eines alten Fehlers?
Testfall	Wie nennt man eine konkrete Eingabe mit erwarteter Ausgabe?
Freigabe	Wie heißt die menschliche Erlaubnis nach dem Review?
Import	Wie heißt das Einlesen einer Datei in das Programm?
Refactoring	Wie heißt das Umstrukturieren bei unverändertem Verhalten?

LearningApps

Suche nach passenden Zuordnungs- und Übungsaufgaben zur testgetriebenen Softwareentwicklung. Der Suchlink ist kein geprüfter einzelner Lernbaustein.

Alternative ohne externe Plattform: Verwende die sechs Begriffspaare aus dem Memory und ordne sie auf Papier zu.

Lückentext

Fülle jeweils den fachlich passenden Begriff ein.

Alternative ohne Quizdarstellung: Schreibe die Sätze mit eigenen Formulierungen ab und ergänze die Lücken aus deinem Lernprotokoll.

Offene Aufgaben

Die Aufgaben sind nach Schwierigkeitsgrad gestaffelt. Bearbeite sie lokal und mit synthetischen Werten.

Leicht

TDD erklären: Erkläre Red, Green und Refactor in eigenen Worten anhand von 80 und 81.
Grenzwerte erkennen: Erstelle eine Tabelle mit den Werten 79, 80 und 81 sowie jeweils begründetem Sollresultat.
Fehlermeldung lesen: Unterscheide einen AssertionError wegen falscher Ausgabe von einem ImportError wegen eines fehlerhaften Pfads.
Änderungen erkennen: Markiere in zwei synthetischen Patches, welcher nur die Fachregel G1 umsetzt.

Standard

Rote Phase dokumentieren: Schreibe zuerst den Test für 81 und protokolliere den erwarteten Fehlschlag.
Kleinste Änderung implementieren: Ergänze die Fallunterscheidung, ohne bisherige Erwartungen zu verändern, und erkläre jede neue Zeile.
Gesamtlauf nachweisen: Führe alle Tests aus und notiere die Ergebnisse vor und nach der Änderung als Tabelle.
Importprüfung spezifizieren: Entwickle fachliche Tests für die Kopfzeile id;wert, gültige Zahlen und den ungültigen Text abc.

Schwer

Fehlerfall verteidigen: Formuliere den Test für den negativen Übungswert und begründe, warum die besondere Modellregel im Anforderungstext stehen muss.
Agentenpatch auditieren: Vergleiche zwei künstliche Diff-Vorschläge; prüfe Teständerungen, Dateigrenzen, Rechte und Regression.
Transfer entwerfen: Plane eine datengesteuerte Prüfung für zwei frei gewählte Grenzwerte und diskutiere gültige Dezimalzahlen.
Qualitätsurteil schreiben: Beurteile einen angeblich grünen Testlauf, bei dem der Agent nur den neuen Test ausgeführt hat, und fordere fehlende Belege nach.

Lernkontrolle

TDD-Reihenfolge: Weise anhand der Konsolenmeldungen nach, ob der rote Test tatsächlich vor dem Produktivcode entstand.
Fachliche Präzision: Erkläre, wie die Ergebnisse für 80 und 81 die Formulierung „größer als 80“ prüfen und weshalb „mindestens 80“ falsch wäre.
Minimale Änderung: Beurteile einen Diff, der neben der Grenzwertfunktion auch Test-Erwartungen und Konfigurationsdateien verändert.
Rückwärtsverträglichkeit: Begründe, warum zwei alte grüne Tests nötig bleiben, auch wenn der neue Test allein besteht.
Berechtigungsgrenzen: Entscheide begründet, ob ein Agent für den Grenzwerttest Netzwerkzugriff oder Schreibrecht auf den Hauptzweig braucht.
Fehlerfallanalyse: Vergleiche die Behandlung von -1 und dem CSV-Text abc und leite zwei verschiedene Tests daraus ab.

Lernnachweis

Abgabeprodukt: Ein kleiner, lokal lauffähiger Übungsordner mit messwerte.py, test_messwerte.py, synthetischen Beispieldaten und einem kurzen Prüfprotokoll. Füge einen Diff oder eine nachvollziehbare Liste der geänderten Zeilen hinzu. Vermeide private Informationen.

Bewertungsbereich	Nachweis	Orientierung
Fachanforderung	G1 und G2 präzise einschließlich Grenzfällen erklärt	20 Prozent
Test zuerst rot	Ursprünglicher AssertionError und zeitliche Reihenfolge belegt	20 Prozent
Minimaler Patch	Keine sachfremden Änderungen und keine manipulierten Sollwerte	20 Prozent
Regression grün	Vollständiger erfolgreicher Testlauf nachvollziehbar	20 Prozent
Fehler und Verantwortung	Fehlerfall fachlich begründet, Agentenrechte und Reviewgrenzen reflektiert	20 Prozent

Selbsteinschätzung: Kannst du auch ohne bezahlten KI-Dienst erklären, weshalb 81 erst rot und später grün ist, warum 80 unverändert bleibt und wer eine Änderung tatsächlich freigeben darf? Wenn nein, arbeite den betroffenen Schritt erneut durch. Dieser Lernnachweis ist eine schulische Übungsleistung, keine Sicherheitszulassung.

OER und Wikipedia

Stand der Quellenprüfung: 22.10.2026. Der fachliche Kern basiert auf den genannten Primärquellen; versionsabhängige Funktionen und Verfügbarkeit können sich ändern. Angaben zu Medien sind den jeweils verlinkten Dateiseiten entnommen. Die Vorkursseite mit curid=60543 war über den öffentlichen Abruf nicht erreichbar; ihre Inhalte wurden nicht unterstellt.

Wikipedia: Testgetriebene Entwicklung – deutschsprachige Einführung und Begriffsklärung, kollaborativ bearbeitet, kein Ersatz für Primärdokumentation.
pytest: Get Started – aktuelle Online-Dokumentation, beim Abruf mit Beispielstand 9.1.1; lokales unittest ist als kostenlose Offline-Alternative vollständig ausreichend.
pytest: Assertions – offizielle Erläuterung zu Assertions, Fehlermeldungen und Ausnahmen.
MCP Security Best Practices – Dokumentpfad 2026-07-28, Leitlinien für Autorisierung, Werkzeug- und Vertrauensgrenzen; sie ersetzen keine organisatorische Freigabe.
NIST AI 600-1: Generative AI Profile – Ausgabe Juli 2024; freiwilliger Risikomanagementrahmen, keine Prüfung oder Zertifizierung dieser App.
Vorausgesetzter MOOCwiki-Lernkurs – vom Auftrag vorgegebene Grundlage, beim Abruf nicht inhaltlich verifiziert.

Quellen und Nutzungsrechte der eingebundenen Wikimedia-Dateien:

Datei	Tatsächliche Dateiseite	Urheber	Lizenz laut Commons
File:Test-driven development.svg	Wikimedia Commons	Excirial; Vektorisierung Jarozwj	CC BY-SA 3.0
File:TDD Global Lifecycle.png	Wikimedia Commons	Xarawn	CC BY-SA 4.0
File:Git-logo.svg	Wikimedia Commons	Jason Long	CC BY 3.0; mögliche Markenrechte gesondert beachten
File:Regresyon-testi.jpg	Wikimedia Commons	Ezgi2015	CC BY-SA 4.0

Medienhinweis: Die Bilddateien werden unverändert unter ihren eigenen Lizenzen genutzt. Zwei YouTube-Videos sind als externe Einbettungen verlinkt, nicht als frei lizenzierte OER behauptet: the native web GmbH, 2022, deutsch und Matt Pocock, 2026, englisch. Upload-Rechte und zukünftige Abspielbarkeit stehen unter Kontrolle der Anbieter; Vorschautitel wurden geprüft, eine dauerhaft garantierte Wiedergabe ist nicht möglich. Für nicht sicher verifizierte, fachlich geeignete Commons-Audio- oder Animationsdateien wird kein Dateiname erfunden. Die Textalternativen, Tabellen und lokalen Übungen ermöglichen die Bearbeitung ohne externe Medien.