Continuous Code Quality und Autonome Agenten

Continuous Code Quality
und Autonome Agenten

Grundlagenmodul · WPF / WASP · Informatik Bachelor · TH Köln · SoSe 26

Code-Qualität kontinuierlich sicherstellen mit automatisierten Tests, CI-Pipelines und reflektiertem KI-Einsatz.

Die Studierenden sichern die Qualität ihres Codes kontinuierlich, indem sie automatisierte Tests implementieren, test-getrieben programmieren, CI-Pipelines mit Quality Gates konfigurieren und KI-Werkzeuge reflektiert nutzen.

Das Modul Continuous Code Quality (CCQ) vermittelt die Grundfähigkeiten, um Code-Qualität in CI-Umgebungen kontinuierlich sicherzustellen. Die Studierenden lernen, automatisierte Tests auf verschiedenen Ebenen zu implementieren, test-getrieben zu entwickeln, CI-Pipelines mit Quality Gates zu konfigurieren und KI-generierte Artefakte kritisch zu bewerten.

Als Referenz dient ein SpringBoot-basiertes Backend-System mit REST-Schnittstelle, Service-Schicht und Persistenzschicht mit PostgreSQL-Datenbank. Die Studierenden testen Controller-, Service- und Persistenzebene sowie deren Zusammenspiel.

Dieses Modul ist Teil der Wahlspezialisierung (WASP) „Continuous Code Quality und Autonome Agenten" (CCQ) und kann auch separat als Wahlpflichtfach belegt werden.

Studiengang: Informatik Bachelor, TH Köln

Modultyp: Grundlagenmodul (5 ECTS) der WASP „CCQ – Continuous Code Quality und Autonome Agenten" (auch separat als WPF belegbar)

Zeitraum: SoSe 26 (20.04. – 27.09.2026)

Charakter: Seminaristischer Unterricht mit Live-Coding, praktische Übungen, Peer-Code-Reviews

Kontakt: Prof. Dr. Uwe van Heesch

Inhalt

Learning Outcome

Die Studierenden sichern die Qualität ihres Codes kontinuierlich (WAS), indem sie

um sicherzustellen, dass der Code die geforderte Funktionalität bereitstellt und definierte Qualitätseigenschaften wie Testbarkeit, Wartbarkeit und Sicherheit kontinuierlich gewährleistet sind (WOZU).

Themen

Didaktik

Technologiestack

Portfolio-Leitfaden

Das Portfolio ist das Git-Repository als Ganzes: Produktivcode, Tests, CI-Pipeline, Commit-Historie und ein strukturierter portfolio/-Ordner mit Dokumentation und Reflexionen. Im mündlichen Walkthrough gehen wir gemeinsam durch beides – Code und Dokumentation.

Aufbau des Repositories

ihr-repo/
├── src/                          # Produktivcode und Tests
├── .gitlab-ci.yml                # CI-Pipeline
├── http/                         # HTTP-Client-Dateien
├── portfolio/                    # Dokumentation und Reflexionen
│   ├── test-strategy.md          # Teststrategie (wächst über den Kurs)
│   ├── week1.md                  # Wöchentliche Reflexion
│   ├── week2.md
│   ├── ...
│   └── week7.md
└── ...

Das Repository hat zwei Säulen:

  1. Der Code – Produktivcode, Tests auf allen Ebenen, Pipeline-Konfiguration und Commit-Historie
  2. Der portfolio/-Ordner – Teststrategie, wöchentliche Reflexionen und Dokumentation von Entscheidungen

Der Code als Portfolio

Der Code ist nicht nur Mittel zum Zweck – er ist ein wesentlicher Teil des Portfolios.

Commit-Historie: Die Commits erzählen eine Geschichte. Insbesondere TDD-Zyklen müssen im Commit-Verlauf nachvollziehbar sein, wobei Red, Green und Refactor jeweils als separate Commits erscheinen sollten. Achten Sie auf aussagekräftige Commit-Messages.

Tests: Die Tests selbst zeigen die Teststrategie – welche Ebenen abgedeckt sind, wie gründlich getestet wird und ob auch Edge Cases und Fehlerfälle berücksichtigt wurden.

Pipeline: Die .gitlab-ci.yml und ihre Entwicklung über die Wochen zeigt, wie die Quality Gates aufgebaut und verbessert wurden.

Der portfolio/-Ordner

test-strategy.md – Teststrategie: Dieses Dokument legen Sie in Woche 4 an und erweitern es bis Woche 7. Es beschreibt, welche Testebenen Sie einsetzen (Unit, Web-Layer, Persistenz, End-to-End), was jede Ebene testet und was bewusst nicht getestet wird, und wie sich die Ebenen voneinander abgrenzen. Darüber hinaus erläutern Sie, welche Test Doubles Sie wo einsetzen und warum, und begründen Ihre Wahl der Testdatenbank (Testcontainers, H2 o. ä.). Schließlich visualisieren Sie Ihre Testpyramide – z. B. als ASCII-Diagramm oder als Beschreibung, die zeigt, wie viele Tests auf welcher Ebene existieren und warum Sie diese Verteilung gewählt haben. Das ist kein akademischer Aufsatz – ein paar klare Absätze mit konkreten Begründungen reichen.

weekN.md – Wöchentliche Reflexionen: Jede Woche schreiben Sie einen kurzen Eintrag (ca. ½–1 Seite). Die folgende Struktur dient als Orientierung:

# Woche N – [Thema]

## Was habe ich gemacht?
Kurze Beschreibung der umgesetzten Features, Tests und
Pipeline-Änderungen mit Verweisen auf relevante Commits oder Dateien.

## Entscheidungen und Begründungen
Welche technischen Entscheidungen habe ich getroffen und warum?

## Wie habe ich gelernt?
Wie bin ich vorgegangen, als ich nicht weiterkam?
Welche Annahme hatte ich, die sich als falsch herausgestellt hat?
Was habe ich diese Woche anders gemacht als letzte Woche, und warum?

## Offene Fragen / Nächste Schritte
Was ist noch unklar? Was würde ich beim nächsten Mal anders machen?

Worauf Sie achten sollten

Begründen, nicht nur beschreiben: Der häufigste Fehler ist rein deskriptive Dokumentation. Erklären Sie warum Sie etwas so gemacht haben und welche Alternativen Sie erwogen haben. Schwach: „Ich habe Mockito verwendet, um den Service zu testen." Besser: „Ich habe das Repository im Service-Test gemockt, weil der Service-Test die Geschäftslogik isoliert prüfen soll, nicht die Datenbankanbindung. Die Datenbankanbindung wird separat im Repository-Test mit Testcontainers getestet."

Grenzen benennen: Zeigen Sie, dass Sie wissen, wo Ihr Ansatz an seine Grenzen stößt. Beispiel: „Meine Coverage liegt bei 85 %, wobei die fehlenden 15 % hauptsächlich Exception-Handler betreffen, die ich bewusst nicht unit-teste, weil sie in den Web-Layer-Tests abgedeckt sind."

KI-Einsatz ehrlich dokumentieren: Es geht nicht darum, ob Sie KI nutzen, sondern wie reflektiert Sie damit umgehen. Halten Sie fest, was Sie generieren lassen haben, was Sie übernommen und was Sie verworfen haben, welche Fehler der generierte Code hatte und was Sie dabei gelernt haben.

Iterative Verbesserung sichtbar machen: Zeigen Sie, dass sich Ihr Ansatz über die Wochen entwickelt hat. Dokumentieren Sie nicht nur den Endzustand, sondern den Weg dorthin – was Sie geändert haben und warum.

Umfang

Das Portfolio soll substanziell, aber nicht aufgebläht sein: ca. ½–1 Seite pro wöchentlicher Reflexion und ca. 1–2 Seiten für die Teststrategie am Ende des Kurses. Beim Code gilt Qualität vor Quantität – es ist besser, wenige Features gut getestet zu haben als viele Features schlecht getestet.

Prüfungsform

Die Bewertung ist individuell. Bewertet werden die praktische Anwendung der Qualitätssicherungstechniken, die Qualität des eigenen Codes und der Tests sowie die Reflexion über den eigenen Lernprozess und den Einsatz von KI-Werkzeugen.

1. Portfolio (40%, prozessbegleitend, individuell)

Jede Person führt von Anfang an ein eigenes Portfolio in einem individuellen Git-Repository, das den Studierenden bereitgestellt wird. Das Portfolio enthält:

2. Mündlicher Walkthrough (60%, individuell)

Im Walkthrough wird der gesamte Inhalt des Portfolios besprochen: Teststrategien, Pipeline-Konfiguration, Code-Qualitätsentscheidungen und Reflexionen.

Bewertungsrubric

Kriterium Gewicht 0 Punkte 1 Punkt 2 Punkte 3 Punkte
Portfolio (40%)
Teststrategie und Testqualität 3 Keine oder nur triviale Tests vorhanden. Keine erkennbare Teststrategie. Tests auf einer Ebene vorhanden (z. B. nur Unit-Tests). Testfälle decken überwiegend Happy Paths ab. Teststrategie ist nicht dokumentiert. Tests auf mehreren Ebenen (Unit, Integration, End-to-End) vorhanden. Test Doubles werden sinnvoll eingesetzt. Teststrategie ist dokumentiert und begründet. Umfassende Teststrategie über alle Schichten (Controller, Service, Persistenz) mit bewusster Abgrenzung der Testebenen. Einsatz von Test Doubles, Testdatenbanken und Container-basierten Testumgebungen ist begründet. Edge Cases und Fehlerfälle werden systematisch abgedeckt.
TDD und Design for Testability 2 Kein TDD-Vorgehen erkennbar. Tests wurden nachträglich geschrieben. TDD wurde in Ansätzen praktiziert. Red–Green–Refactor-Zyklen sind vereinzelt erkennbar, aber nicht durchgängig. TDD wurde durchgängig praktiziert. Red–Green–Refactor-Zyklen sind im Commit-Verlauf nachvollziehbar. Code zeigt erkennbares Design for Testability. TDD wurde konsequent angewendet und hat nachweislich das Design beeinflusst. Refactoring-Schritte sind dokumentiert und begründet. Der Zusammenhang zwischen Testbarkeit und Softwaredesign wird reflektiert.
CI/CD-Pipeline und Quality Gates 2 Keine Pipeline vorhanden oder nicht funktionsfähig. Pipeline ist funktionsfähig und enthält grundlegende Jobs (Build, Test). Quality Gates sind konfiguriert. Pipeline enthält differenzierte Stages mit Coverage-Prüfung und weiteren Quality Gates. Die Konfiguration ist dokumentiert und begründet. Pipeline ist umfassend mit mehreren Quality Gates (Coverage, Mutation Testing, Linting, SAST). Schwellenwerte sind begründet gewählt. Die Pipeline wurde iterativ verbessert und die Verbesserungen sind dokumentiert.
Prozessdokumentation und Reflexion 1 Keine oder nur minimale Dokumentation. Keine Reflexion erkennbar. Dokumentation ist lückenhaft. Reflexion bleibt deskriptiv (Was wurde getan?) ohne kritische Einordnung. Entscheidungen und Lernfortschritte sind dokumentiert. Reflexion benennt konkret, was funktioniert hat und was nicht, und leitet daraus Änderungen ab. Durchgängige Dokumentation des Lernprozesses. Reflexion ordnet Ergebnisse in den Gesamtkontext ein, erkennt Grenzen des eigenen Ansatzes und formuliert offene Fragen. KI-Einsatz wird kritisch reflektiert.
Mündlicher Walkthrough (60%)
Fachliche Begründung von Entscheidungen 4 Entscheidungen können nicht begründet werden oder werden ausschließlich mit Verweis auf externe Quellen erklärt. Einige Entscheidungen werden begründet, aber ohne Bezug zu den vermittelten Konzepten (z. B. Testpyramide, TDD, Coverage-Interpretation). Entscheidungen werden nachvollziehbar begründet. Der Bezug zwischen den vermittelten Konzepten und der eigenen Umsetzung wird an konkreten Beispielen hergestellt. Entscheidungen werden auf Nachfrage zu jedem Aspekt begründet. Alternativen und deren Vor- und Nachteile werden differenziert diskutiert.
Transferleistung und Beurteilung 4 Keine Transferleistung erkennbar. Erkenntnisse werden nicht über den eigenen Fall hinaus eingeordnet. Erkenntnisse bleiben weitgehend auf den eigenen Fall beschränkt. Verallgemeinerungen sind oberflächlich. Es wird nachvollziehbar beurteilt, welche Qualitätssicherungsmaßnahmen in welchem Kontext wirksam sind und wo deren Grenzen liegen. Erkenntnisse werden über den eigenen Fall hinaus verallgemeinert. Es wird fundiert beurteilt, wie verschiedene Qualitätssicherungsmaßnahmen zusammenwirken und unter welchen Bedingungen sie ihren Zweck erfüllen.
Umgang mit kritischen Nachfragen 4 Nachfragen können nicht beantwortet werden oder führen zu Widersprüchen. Nachfragen werden beantwortet, aber Antworten bleiben an der Oberfläche. Nachfragen werden sachlich und differenziert beantwortet. Wissenslücken werden offen benannt. Nachfragen werden ohne Hilfestellung fundiert und reflektiert beantwortet, auch über den unmittelbaren Kontext des eigenen Projekts hinaus.

Notenberechnung

Insgesamt sind maximal 60 Punkte erreichbar (20 Gewichtspunkte × 3 Punkte). 0 Punkte bei „Teststrategie und Testqualität", „CI/CD-Pipeline und Quality Gates" oder „Prozessdokumentation und Reflexion" führen automatisch zum Nichtbestehen.

NotePunkte
1,053–60
1,350–52
1,747–49
2,044–46
2,341–43
2,738–40
3,035–37
3,332–34
3,728–31
4,024–27
5,00–23

© Prof. Dr. Uwe van Heesch – TH Köln · Letzte Änderung: 16.04.2026