Codequalität, Metriken und Mindset für Studierende

Testen in der Hochschullehre zu vermitteln ist schwierig, weil Studierenden der Praxisbezug fehlt: Kleine, überschaubare Übungsbeispiele machen den Nutzen von Tests kaum spürbar. Komplexere Projekte mit echter Infrastruktur, Techniken wie Test-Driven Development und Behavior Driven Development sowie der bewusste Umgang mit KI-generierten Code schaffen das nötige Verständnis.

Das Wichtigste in Kürze

• Studierende verstehen den Sinn von Tests erst dann, wenn die Aufgaben komplex genug sind: Einfache Übungsbeispiele erzeugen keine echte Motivation, weil der Nutzen nicht spürbar wird.
• Test-Driven Development eignet sich besonders gut für die Lehre, weil das Rot-Grün-Schema eine klar überprüfbare Struktur vorgibt, die Anfänger direkt anwenden können.
• Schlechte Softwarearchitektur macht gutes Testen strukturell unmöglich: Wer Domain-Logik und Datenbanklogik vermischt, kann Businesslogik nicht ohne laufende Datenbank testen.
• Code-Coverage-Metriken wie das 75%-Quality-Gate in SonarCube verführen Studierende dazu, Tests nur zum Erfüllen der Zahl zu schreiben, statt zur Qualitätssicherung.
• Wer KI-generierten Code einsetzt, ohne ihn zu verstehen, verliert die Kontrolle darüber, was im System läuft, was in sicherheitskritischen Domänen wie Banking oder Flugsicherung direkt zum Problem wird.

Warum Testen in der Lehre so schwer zu vermitteln ist

Studierenden das Testen beizubringen, scheitert oft an einem simplen Problem: Der Sinn ist nicht spürbar, solange die Aufgaben trivial bleiben. Wer eine einfache Funktion schreibt, über die er lange nachgedacht hat und von der er weiß, dass sie funktioniert, sieht keinen Grund, sie auch noch zu testen.

Kai Renz, seit acht Jahren Professor für Software Engineering an der Hochschule Darmstadt, beschreibt diese Hürde als doppelt. Am Anfang können viele noch gar nicht richtig programmieren. Tests zu schreiben wirkt dann doppelt abstrakt, weil das Fundament fehlt. Ist diese erste Hürde genommen, kommt die nächste: kleine, überschaubare Beispiele liefern keinen glaubwürdigen Anlass für Tests.

Das klassische Argument zieht in dieser Phase nicht. Der Hinweis, dass Tests später in der echten Softwareindustrie vor Regressionen und Unsicherheit bei der Weiterentwicklung schützen, bleibt anekdotisch. Es ist eine erzählte Geschichte über eine Zukunft, die für Lernende noch nicht existiert.

Verschärft wird das durch generative KI. Wenn ChatGPT die korrekte Lösung ohnehin ausspuckt, stellt sich die Frage nach dem Sinn eines Tests umso dringlicher.

Komplexe Projekte schaffen den Anlass, den triviale Beispiele nicht liefern

Der Hebel gegen die fehlende Motivation ist Komplexität. Sobald ein Projekt realistisch genug wird, entsteht der Bedarf für Tests von selbst.

In Darmstadt simuliert ein Software-Engineering-Praktikum dafür einen Pizza-Shop. Jede Gruppe betreibt ein eigenes Kubernetes-Cluster mit echter Infrastruktur, bei dem auch Integrationstests notwendig werden. Die Studierenden werden bewusst ins kalte Wasser geworfen.

Das Ergebnis ist gespalten. Bei einem Teil zündet das Prinzip, sie verstehen, warum sie testen. Andere fragen vor allem, was sie tun müssen, um das Testat zu bekommen. Bei ihnen bleibt der Funke aus. Diese Spaltung ist kein Versagen der Methode, sondern Realität in einer heterogenen Studierendenschaft.

Konzeptionelles Verständnis schlägt Tool-Wissen

Der wichtigste Lernertrag liegt nicht in der Beherrschung eines konkreten Tools, sondern im konzeptionellen Verständnis. Die Industrie ist so schnelllebig, dass jedes spezifische Werkzeug schnell veraltet.

Konkrete Techniken und Tools werden trotzdem vermittelt, von Unit-Tests über Integrations- und End-to-End-Tests bis zu UI-Tests. Der Aufbau eines Tests steht dabei im Zentrum: das AAA-Pattern konsequent anwenden, klar entscheiden, was das System under Test überhaupt ist. Eine einzelne Klasse? Eine komplette Funktionalität? Auf welcher Ebene bewege ich mich gerade?

Genau diese Entscheidungen treffen erfahrene Entwickler fast automatisch. Brauche ich eine Testdatenbank? Mocke ich ein Framework oder nicht? Wer das Zusammenspiel der Komponenten kennt, entscheidet bewusst. Wer es nicht kennt, braucht klare Anleitung als Einstieg.

Test-Driven Development eignet sich besonders gut für die Lehre

Test-Driven Development hat ein einfaches, klar verständliches Schema, das sich im Hörsaal gut nachvollziehen lässt. Zuerst der Test, dann die Funktionalität. Der Test ist erst rot, vielleicht kompiliert anfangs nicht einmal alles, danach folgt der Code.

Die häufigste Rückfrage der Studierenden lautet: Woher weiß ich, was ich teste, wenn die Funktion noch gar nicht existiert? Daraus entstehen halb-philosophische Diskussionen darüber, was man wissen muss, um etwas zu tun.

Die Antwort ist pragmatisch: Wenn du weißt, was du als Nächstes programmieren würdest, weißt du auch, was rauskommen soll. Und damit weißt du, wie der Test aussieht. TDD hilft hier, weil es den Fokus auf einen einzigen kleinen Schritt in Richtung der Funktionalität verengt.

Verstärkt wird das durch Pair-Programming mit Driver und Navigator sowie durch Coding-Sessions im Hörsaal nach dem Prinzip des Mob-Programmings. Einer programmiert, alle schauen zu. Das funktioniert, bleibt aber anspruchsvoll, weil sehr gute und sehr unerfahrene Studierende im selben Raum sitzen.

Behavior Driven Development bringt die Nutzerperspektive in den Test

Behavior Driven Development verschiebt den Blick weg von der Umsetzung hin zur Anwendungs- und Nutzerseite. Statt zu fragen, wie etwas implementiert ist, fragt BDD, was getestet werden soll und wie sich ein Testfall beschreiben lässt.

Diese Technik kommt in einem Wahlpflichtfach namens “Professionelles Testen” zum Einsatz. Über vierzehn Wochen werden die Teilnehmenden mit dem gesamten Spektrum konfrontiert, von Backend-Tests über verschiedene Programmiersprachen und Tools bis zu UI-Tests mit Playwright. Die Lernkurve ist steil, das mitgenommene Wissen breit.

Der Effekt zeigt sich im Beruf. Ehemalige berichten, dass sie Gelerntes direkt einsetzen konnten. Manche bringen in Firmen, in denen Testen noch nicht selbstverständlich gelebt wird, mehr Wissen mit als die Kollegen vor Ort. Frische Leute sind oft der einzige Weg, Qualitätsdenken in ein Unternehmen zu tragen, das zwanzig Jahre ohne ausgekommen ist.

Architektur entscheidet darüber, ob ein System testbar ist

Gute Testbarkeit hängt maßgeblich von der Softwarearchitektur ab. Systeme, die schwer zu testen sind, vermengen in der Regel Dinge, die getrennt gehören.

Das klarste Beispiel ist die Trennung von Domain-Logik und Controller-Logik. Ansätze wie hexagonale oder funktionale Architektur zeigen ihre Stärke erst, wenn man sie konsequent durchzieht. Der Preis ist sichtbarer Overhead: viele Hilfsklassen, die Objekte aus der Datenbanklogik in die Businesslogik kopieren.

Genau an dieser Stelle steigen Studierende oft aus. Sie haben bereits eine Klasse, die mit der Datenbank gekoppelt ist, und fragen, warum das ein Problem sein soll. Die Antwort wird greifbar, sobald man die Businesslogik testen will: Musst du erst eine Datenbank erzeugen, um die Businesslogik zu prüfen, ist sie nicht sauber getrennt.

Was tun, wenn ein bestehendes System sich nicht testen lässt

Die typische Falle ist eine Schockstarre. Das Team steht vor einem System, das schlecht testbar ist, und sieht keinen Ansatzpunkt. Es bräuchte Refactoring, aber das geht ohne absichernde Tests kaum, und die Tests gehen wegen der Architektur kaum. Ein echter Teufelskreis.

Der pragmatische Einstieg führt über das Neue. Neue Funktionalität wird konsequent sauber gebaut und getestet. Daran erlebt das Team, was eine gute Architektur bringt: leichteres Refactoring, Tests auf allen Ebenen, statische Analyse ohne offene Befunde.

Dieses Verständnis sickert mit der Zeit in den Altbestand ein. Bei sehr großen, alten Systemen lässt sich das nie vollständig umsetzen. Und selbst in der Neuentwicklung droht die Gefahr, dieselben Fehler zu wiederholen. Deshalb braucht es ein gemeinschaftliches Denken über Qualität im Team.

Metriken sind Mittel, nicht Ziel

Eine Code-Coverage von 75 Prozent ist kein Selbstzweck. Genau das verkennen Teams, die nur deshalb Tests schreiben, weil ein rotes Quality Gate grün werden soll.

Im Praktikum wird SonarQube als Tool für statische Code-Analyse eingesetzt, mit einem Quality Gate, das eine Coverage über 75 Prozent verlangt. Schaffen Teams das zunächst nicht, schreiben manche einfach irgendwelche Tests, bis die Zahl stimmt. Damit kippt das Mindset in die falsche Richtung.

Der Grundsatz lautet: Du schreibst einen Test nicht, damit eine Zahl grün wird, sondern damit die Qualität steigt. Spannender als die reine Coverage sind ohnehin die Aussagen zur Codequalität, etwa zur Komplexität.

Nicht-funktionale Tests werden bewusst ausgelagert

Security, Usability und Performance lassen sich im Software-Engineering-Teil kaum unterbringen, weil der Themenkanon dort bereits randvoll ist. Darmstadt löst das über spezialisierte Veranstaltungen.

IT-Security hat eine eigene Lehrveranstaltung und eine starke Forschergruppe im Rücken, sowohl auf technischer als auch auf Usability-Ebene. Für Usability gibt es zusätzlich eine eigene Veranstaltung zu Human-Computer-Interaction, die fragt, wie sich Funktionalität überhaupt sinnvoll umsetzen lässt.

Eine engere Verzahnung dieser Module wäre wünschenswert, scheitert aber an zwei Hürden. Lehrende arbeiten gerne autonom, eine Abstimmung ist mühsam. Und Studierende stünden vor einer deutlich größeren Workload, wenn ein Modul ein weiteres voraussetzt.

Performance-Tests werden über die Quadranten des agilen Testens eingeordnet, mehr nicht. Ein Lasttest mit 500 Pizzabestellungen hat nichts mit einem realen System zu tun und bliebe fake. Übungen sollen Real-World-Impact haben, statt Aufgaben zu simulieren, die im Bildungskontext leer bleiben.

KI im Studium: Verantwortung bleibt beim Menschen

Generative KI ist für die aktuelle Generation Studierender selbstverständlich. Die Lehre reagiert darauf mit klaren Grenzen dort, wo es zählt, und mit Offenheit überall sonst.

In der Grundlagen-Veranstaltung Programmieren steht am Ende eine praktische Prüfung am Rechner ohne Internetzugang. Wer sich die Lösungen vorher nur generieren ließ, kann die grundlegenden Programmiertechniken in der Prüfung nicht. In den Praktika gilt dagegen: KI darf genutzt werden, aber die Verantwortung für das Abgegebene bleibt bei den Studierenden. Sie müssen erklären können, was sie getan haben.

Ein Vorfall zeigt das Risiko konkret. Beim Entwickeln eines neuen Features für das Pizza-Projekt war die gesuchte Funktionalität bereits im Code vorhanden. In der Commit History fand sich ein Commit, der fast das komplette Projekt austauschte. Ein Student hatte den Code unter Abgabestress an ChatGPT gegeben mit der Bitte, Fehler zu finden. Die KI fügte dabei ungefragt die Funktionalität hinzu.

Wenn du bei einer Bank arbeiten würdest oder in der Flugsicherung oder bei einem Bremsenhersteller: Könntest du gut schlafen, wenn du Code committed hättest, von dem du gar nicht weißt, dass er da ist?

Kai Renz

Der Student gab den Vorgang ehrlich zu. Genau das machte das Gespräch lehrreich. Der Lerneffekt: KI hilft, aber man muss selbst wissen, was man tut.

Worin der bleibende Skill liegt

Wer nur ChatGPT bedienen kann, hat keine Kompetenz, die einen Arbeitgeber überzeugt. Diese Botschaft bekommen Studierende deutlich, die ihre Abgaben offen rein über KI lösen.

Ein Abschluss lässt sich theoretisch mit KI erreichen, ohne viel zu verstehen, solange man die Klausuren irgendwie übersteht. Aber Prompting allein ist ein kurzfristiger Skill, der sich vermutlich wieder vereinfacht, je natürlicher man mit KI sprechen kann.

Zwei Fähigkeiten tragen langfristig. Die erste ist Kommunikation mit Menschen: wirklich zu erfassen, was das Gegenüber will. Das lässt sich schlecht delegieren. Die zweite ist Kontrolle über das Ausgespuckte. Ist das plausibel? Verstehe ich es? Behalte ich den Überblick?

Den Überblick hast du allerdings erst mit Erfahrung. Wer noch keine Erfahrung hat, hat keinen Überblick. Darin liegt das eigentliche Dilemma einer Generation, die mit KI startet, bevor sie das Urteilsvermögen aufgebaut hat, deren Ergebnisse zu prüfen.

KI versteht den Kontext nicht von selbst

Manche Rahmenbedingungen muss man der KI explizit mitgeben, weil sie sie nicht von allein berücksichtigt. Logging ist ein gutes Beispiel.

Logging-Frameworks samt gutem Aufbau von Messages lassen sich schnell vermitteln, und der Nutzen leuchtet ein. Dann kommt die Gegenfrage: Darfst du überhaupt alles loggen? Verlangt jemand die Löschung seiner Daten, das System hat aber protokolliert, welche Seiten diese Person angesehen hat, bekommst du das jemals wieder aus dem Log heraus?

Solche Grenzen ergeben sich aus Datenschutz, Copyright und Urheberrecht. Auch die Frage, wohin Quellcode aus einer Firma überhaupt geschickt wird und welcher Server mitliest, gehört dazu. Eine KI versteht diese Implikationen nicht automatisch. Du musst sie ihr vorgeben.