Glanz: AI MOOC Plugin d45987c019eb5c93da35f079165eefa5

2026-10-21T22:08:33Z

AI MOOC Plugin d45987c019eb5c93da35f079165eefa5

Neue Seite

{{T}}

{{BR}}
= 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:''' [https://moocwiki.org/index.php?curid=60543 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.

{{BR}}
= Anforderungen vor Code: der TDD-Gedanke =
{{BR}}
== 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).

[[File:Test-driven development.svg|500px|frameless|center|alt=Englisches Ablaufdiagramm des testgetriebenen Entwicklungszyklus mit Test, Implementierung und erneuter Prüfung]]
'''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.

{{BR}}
== Drei überprüfbare Qualitätskriterien ==
{| class="wikitable"
! 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.

{{BR}}
== 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.

{{#ev:youtube|https://www.youtube.com/watch?v=H943sC8r7nQ|500|center}}
'''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.

{{BR}}
= Fachanforderungen in ausführbare Tests übersetzen =
{{BR}}
== 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.

{{BR}}
== 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.

<pre>
# 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()
</pre>
'''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.

{{BR}}
== Importprüfung als nächster Entwicklungsauftrag ==
Die spätere Datei '''werte.csv''' enthält ausschließlich synthetische Zeilen:
<pre>
id;wert
M01;50
M02;80
M03;81
</pre>
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.

{{BR}}
= Geführtes Praxisbeispiel: Rot, minimale Änderung, Regression =
{{BR}}
== 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:
<pre>
# messwerte.py – Ausgangsversion
def bewerte_wert(wert, grenze=80):
return "ok"
</pre>
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.

{{BR}}
== Kleinste Implementierung ==
Erst nach dem dokumentierten roten Test änderst du '''nur''' die Produktivfunktion:
<pre>
# messwerte.py – minimale Änderung für G1
def bewerte_wert(wert, grenze=80):
if wert > grenze:
return "ueber"
return "ok"
</pre>
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.

{{BR}}
== 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.

[[File:TDD Global Lifecycle.png|480px|frameless|center|alt=Englisch beschriftetes Schaubild zu wiederholten TDD-Zyklen vom Test über Implementierung zur erneuten Prüfung]]
'''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.

{{BR}}
== 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:
<pre>
def test_negativer_wert(self):
with self.assertRaises(ValueError):
bewerte_wert(-1)
</pre>
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:
<pre>
if wert < 0:
raise ValueError("Negativer Uebungswert")
</pre>
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.

{{BR}}
= KI-Agenten kontrolliert an TDD beteiligen =
{{BR}}
== 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''.

{{BR}}
== 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.

[[File:Git-logo.svg|310px|frameless|center|alt=Orangefarbenes Git-Logo zur Kennzeichnung der Versionsverwaltung und Änderungsprüfung]]
'''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.

{{BR}}
== Fehlerarten unterscheiden ==
{| class="wikitable"
! 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.

{{#ev:youtube|https://www.youtube.com/watch?v=hYZdIwFIy-c|480|center}}
'''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.

{{BR}}
= Transfer: selbstständig eine sichere Änderung nachweisen =
{{BR}}
== 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.

[[File:Regresyon-testi.jpg|390px|frameless|center|alt=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.

{{BR}}
== Prüfprotokoll für das Lernprodukt ==
{| class="wikitable"
! 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.

{{BR}}
= 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.

{{BR}}
== Quiz: Teste dein Wissen ==
{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{MC}}
'''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)
{{E}}

{{BR}}
== Memory ==
Ordne Fachbegriff und Bedeutung zu.
<div class="memo-quiz">
{|
|-
| 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
|}
{{E}}

{{BR}}
== Drag-and-Drop ==
Ordne die Schritte den passenden Beobachtungen zu.
<div class="lueckentext-quiz">

{| class="wikitable"
! 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
|}
{{E}}

{{BR}}
== Kreuzworträtsel ==
Trage die gesuchten Fachwörter ein.
<div class="kreuzwort-quiz">
{|
|-
| 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?
|}
{{E}}

{{BR}}
== LearningApps ==
Suche nach passenden Zuordnungs- und Übungsaufgaben zur testgetriebenen Softwareentwicklung. Der Suchlink ist kein geprüfter einzelner Lernbaustein.
<iframe> https://learningapps.org/index.php?s=Testgetriebene+Softwareentwicklung+mit+KI-Agenten </iframe>
'''Alternative ohne externe Plattform:''' Verwende die sechs Begriffspaare aus dem Memory und ordne sie auf Papier zu.

{{BR}}
== Lückentext ==
Fülle jeweils den fachlich passenden Begriff ein.
<quiz display=simple>
{'''Vervollständige den Text.'''<br>
|type="{}"}
Bei TDD wird vor der Implementierung ein { Test } geschrieben.
Ein erwarteter Fehlschlag heißt { Rot }.
Die kleinste passende Änderung führt zur Phase { Grün }.
Anschließend werden alle bestehenden Prüfungen als { Regressionstests } erneut ausgeführt.
Die Grenze 80 bleibt bei der Bedingung größer als 80 noch { ok }.
Ein negativer Wert löst in unserem Modell einen { ValueError } aus.
Ein Agent bekommt nur die benötigten { Berechtigungen }.
Die fachliche Endentscheidung liegt bei einem menschlichen { Reviewer }.
</quiz>

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

{{BR}}
= Offene Aufgaben =
Die Aufgaben sind nach Schwierigkeitsgrad gestaffelt. Bearbeite sie lokal und mit synthetischen Werten.

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

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

{{BR}}
=== Schwer ===
# [[Testfall|Fehlerfall verteidigen]]: Formuliere den Test für den negativen Übungswert und begründe, warum die besondere Modellregel im Anforderungstext stehen muss.
# [[Software-Review|Agentenpatch auditieren]]: Vergleiche zwei künstliche Diff-Vorschläge; prüfe Teständerungen, Dateigrenzen, Rechte und Regression.
# [[Testautomatisierung|Transfer entwerfen]]: Plane eine datengesteuerte Prüfung für zwei frei gewählte Grenzwerte und diskutiere gültige Dezimalzahlen.
# [[Softwarequalität|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.

{{:Offene Aufgabe - MOOC erstellen}}

{{BR}}
= Lernkontrolle =
# [[Testgetriebene Entwicklung|TDD-Reihenfolge]]: Weise anhand der Konsolenmeldungen nach, ob der rote Test tatsächlich vor dem Produktivcode entstand.
# [[Anforderungsanalyse|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.
# [[Versionsverwaltung|Minimale Änderung]]: Beurteile einen Diff, der neben der Grenzwertfunktion auch Test-Erwartungen und Konfigurationsdateien verändert.
# [[Regressionstest|Rückwärtsverträglichkeit]]: Begründe, warum zwei alte grüne Tests nötig bleiben, auch wenn der neue Test allein besteht.
# [[Sichere Softwareentwicklung|Berechtigungsgrenzen]]: Entscheide begründet, ob ein Agent für den Grenzwerttest Netzwerkzugriff oder Schreibrecht auf den Hauptzweig braucht.
# [[Datenvalidierung|Fehlerfallanalyse]]: Vergleiche die Behandlung von -1 und dem CSV-Text abc und leite zwei verschiedene Tests daraus ab.

{{BR}}
= 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.

{| class="wikitable"
! 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.

{{BR}}
= 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.

* [https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung Wikipedia: Testgetriebene Entwicklung] – deutschsprachige Einführung und Begriffsklärung, kollaborativ bearbeitet, kein Ersatz für Primärdokumentation.
* [https://docs.pytest.org/en/stable/getting-started.html pytest: Get Started] – aktuelle Online-Dokumentation, beim Abruf mit Beispielstand 9.1.1; lokales unittest ist als kostenlose Offline-Alternative vollständig ausreichend.
* [https://docs.pytest.org/en/stable/how-to/assert.html pytest: Assertions] – offizielle Erläuterung zu Assertions, Fehlermeldungen und Ausnahmen.
* [https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices MCP Security Best Practices] – Dokumentpfad 2026-07-28, Leitlinien für Autorisierung, Werkzeug- und Vertrauensgrenzen; sie ersetzen keine organisatorische Freigabe.
* [https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf NIST AI 600-1: Generative AI Profile] – Ausgabe Juli 2024; freiwilliger Risikomanagementrahmen, keine Prüfung oder Zertifizierung dieser App.
* [https://moocwiki.org/index.php?curid=60543 Vorausgesetzter MOOCwiki-Lernkurs] – vom Auftrag vorgegebene Grundlage, beim Abruf nicht inhaltlich verifiziert.

'''Quellen und Nutzungsrechte der eingebundenen Wikimedia-Dateien:'''
{| class="wikitable"
! Datei !! Tatsächliche Dateiseite !! Urheber !! Lizenz laut Commons
|-
| File:Test-driven development.svg || [https://commons.wikimedia.org/wiki/File:Test-driven_development.svg Wikimedia Commons] || Excirial; Vektorisierung Jarozwj || [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0]
|-
| File:TDD Global Lifecycle.png || [https://commons.wikimedia.org/wiki/File:TDD_Global_Lifecycle.png Wikimedia Commons] || Xarawn || [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]
|-
| File:Git-logo.svg || [https://commons.wikimedia.org/wiki/File:Git-logo.svg Wikimedia Commons] || Jason Long || [https://creativecommons.org/licenses/by/3.0/ CC BY 3.0]; mögliche Markenrechte gesondert beachten
|-
| File:Regresyon-testi.jpg || [https://commons.wikimedia.org/wiki/File:Regresyon-testi.jpg Wikimedia Commons] || Ezgi2015 || [https://creativecommons.org/licenses/by-sa/4.0/ 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: [https://www.youtube.com/watch?v=H943sC8r7nQ the native web GmbH, 2022, deutsch] und [https://www.youtube.com/watch?v=hYZdIwFIy-c 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.

<iframe> https://de.m.wikipedia.org/wiki/Testgetriebene_Entwicklung </iframe>

{{BR}}
= Verknüpfte Lernbereiche =
{| align=center
{{:D-Tab}}
'''[[Softwareentwicklung]]'''
# [[Testgetriebene Entwicklung]]
# [[Unit-Test]]
# [[Regressionstest]]
# [[Softwarequalität]]
'''[[Programmierung]]'''
# [[Python]]
# [[CSV]]
# [[Datenvalidierung]]
# [[Git]]
'''[[Künstliche Intelligenz]]'''
# [[Coding-Agent]]
# [[Anforderungsanalyse]]
# [[Software-Review]]
# [[IT-Sicherheit]]
|}

[[Category:Sprache:Deutsch]]
[[Category:Locale:de-DE]]
[[Category:Informatik]]
[[Category:Softwareentwicklung]]
[[Category:Berufsausbildung]]
[[Category:Programmierung]]
[[Category:Künstliche Intelligenz]]

{{BR}}
= aiMOOC-Projekte =
[[Category:AI_MOOC]] [[Category:GPT aiMOOC]]
{{MT}}

Testgetriebene Softwareentwicklung mit KI-Agenten - Versionsgeschichte

Glanz: AI MOOC Plugin d45987c019eb5c93da35f079165eefa5