Übungsaufgaben zu Unit-Tests, Testfällen und Fehlersuche im Code

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Unit-Tests, Testfällen und
Fehlersuche im Code“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/unit-tests
- https://oer-informatik.de/blackboxtests
- https://oer-informatik.de/codecoverage
- https://oer-informatik.de/java-junit-mockito
- https://oer-informatik.de/python_einstieg_pytest
- Stilbeispiel: https://oer-informatik.de/unit-tests-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Unit-Tests
- JUnit
- Parametrisierte Tests
- Testfälle
- Äquivalenzklassen
- Schreibtischtest
- Datenverlaufstabelle
- Anweisungsüberdeckung
- Fehlersuche
- Debugger

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je Klasse mit passenden Grenzwerten 1 P.

Gut überlegt ist eine weitere Unterteilung der gültigen Eingaben nach dem Ergebnis: Kosten, die sich ohne Rest teilen lassen (z. B. 6000 / 4), und Kosten, bei denen aufgerundet werden muss (z. B. 1000 / 3 = 333,33… → 334). Der Wert 0 bei personen ist ein wichtiger Sonderfall, weil er ohne Prüfung zu einer Division durch 0 führt.

@ParameterizedTest
@CsvSource({ "6000, 4, 1500", "1000, 3, 334", "0, 2, 0", "100000, 20, 5000", "2501, 2, 1251" })
void anteilWirdAufVollenCentAufgerundet(int gesamtCent, int personen, int erwarteterAnteil) {
    assertEquals(erwarteterAnteil, anteilInCent(gesamtCent, personen));
}

@ParameterizedTest
@ValueSource(ints = { 0, 1, 21 })
void ungueltigePersonenzahlWirftException(int personen) {
    assertThrows(IllegalArgumentException.class, () -> anteilInCent(5000, personen));
}

Bewertung: erster Test mit @ParameterizedTest, @CsvSource und passenden Methodenparametern 1 P, mindestens vier sinnvolle Datensätze mit richtig berechnetem erwartetem Anteil 2 P (davon ein Fall mit Aufrunden); zweiter Test mit @ValueSource 1 P, assertThrows mit richtiger Ausnahmeklasse und Lambda 1 P, Werte aus den ungültigen Klassen 1 P. Ein parametrisierter Test meldet jeden Datensatz einzeln – anders als mehrere assertEquals in einer Testmethode, bei denen JUnit nach dem ersten Fehlschlag abbricht.

Je Fehlschlag 1 P (Entscheidung mit Begründung).

• [2] 1000, 3: Code falsch. 1000 / 3 = 333,33…; die Anforderung verlangt Aufrunden auf 334. Zeile 8 rechnet mit ganzzahliger Division und schneidet die Nachkommastellen ab.

• [3] 0, 5: Test falsch. Bei Kosten von 0 Cent ist der Anteil 0 Cent; die Anforderung kennt keinen Mindestbeitrag. Jonas hat den erwarteten Wert nicht aus der Anforderung abgeleitet. Der Datensatz wird zu 0, 5, 0 korrigiert.

• [1] personen = 0: Code falsch. Die ungültige Personenzahl wird nicht abgefangen; erst die Division in Zeile 8 bricht mit ArithmeticException (Division durch 0) ab.

• [2] personen = 1 und [3] personen = 21: Code falsch. Beide Werte liegen außerhalb von 2 bis 20, die Methode liefert aber einen Anteil (5000 bzw. 238) statt einer IllegalArgumentException.

Je Zeile 2 P (1 P Position, 1 P Korrektur).

Ebenso richtig für Zeile 8: return (int) Math.ceil((double) gesamtCent / personen);. Nach der Korrektur von Code und Testdatensatz [3] werden alle Tests erneut ausgeführt (Regressionstest).

Es ist ein semantischer (logischer) Fehler: Die Zeile ist gültiges Java, das Programm läuft, liefert aber ein falsches Ergebnis (1 P). Mit && müssten beide Teilbedingungen zugleich wahr sein. Eine Zahl kann aber nicht gleichzeitig kleiner als 2 und größer als 20 sein, deshalb ist der Ausdruck immer falsch und Zeile 6 wird nie ausgeführt (1 P). Gemeint ist „außerhalb des Bereichs“, also eine Oder-Verknüpfung (||). Erst der Laufzeitfehler bei personen = 0 zeigt, dass etwas nicht stimmt – die eigentliche Ursache liegt aber in Zeile 5, nicht in Zeile 8, wo die Ausnahme entsteht (1 P).

Ein Unit-Test soll nur die Logik einer Methode isoliert prüfen. Mit einer echten Datenbank wäre er langsamer und nicht mehr unabhängig und wiederholbar: Sein Ergebnis hinge vom Datenbestand, von anderen Tests und von der Erreichbarkeit des Servers ab (2 P). Abhängigkeiten werden im Unit-Test deshalb durch Stubs oder Mocks ersetzt. Das Zusammenspiel von Code und Datenbank prüft ein Integrationstest (1 P).

Je Schwäche 1 P für Beschreibung mit Eigenschaft, 1 P für die Verbesserung.

• Nicht selbstvalidierend (self-validating): aktivitaetAnlegen() enthält keine Zusicherung, sondern gibt nur einen Text aus. Der Test ist immer grün, ob das Anlegen klappt oder nicht. Verbesserung: assertEquals(1, service.anzahl()); statt der Ausgabe.

• Nicht unabhängig (independent): zweiteAktivitaetAnlegen() hängt über die statische Variable angelegt davon ab, ob der andere Test vorher lief. JUnit legt keine Reihenfolge fest; je nach Reihenfolge erwartet der Test 1 oder 2, während service.anzahl() wegen des neuen Service immer 1 ist. Verbesserung: keinen gemeinsamen Zustand zwischen Tests; jeder Test baut seine Ausgangslage selbst auf und erwartet einen festen Wert.

• Nicht wiederholbar (repeatable): LocalDateTime.now().plusHours(24) liegt genau auf der Grenze der Regel. Bis der Service prüft, sind schon einige Millisekunden vergangen, sodass der Test je nach Timing und Rechner mal besteht und mal nicht. Verbesserung: feste Zeitpunkte verwenden, z. B. eine feste Uhr (Clock.fixed(...)) in den Service geben, und die Grenze gezielt mit „24 Stunden“ und „24 Stunden minus 1 Minute“ testen.

Ebenso richtig: sprechendere Namen, die das erwartete Verhalten nennen; je Test genau ein Verhalten.

• Ursache: Java zählt mit length() keine sichtbaren Zeichen, sondern UTF-16-Einheiten. Ein Emoji wie die Flamme (U+1F525) liegt außerhalb des Basisbereichs von Unicode und belegt zwei Einheiten; der Titel hat für Java also 41 „Zeichen“. Emojis mit Hautton oder zusammengesetzte Emojis belegen noch mehr (1 P).

• Weitere Stelle: Auch die Datenbank muss mitspielen. Emojis brauchen vier Byte; eine MariaDB-Spalte mit dem Zeichensatz utf8mb3 (in älteren Versionen das Standard-utf8) kann sie nicht speichern, nötig ist utf8mb4 (1 P).

• Vorgehen: Nicht selbst entscheiden, sondern mit Yusuf bzw. Clara Neumann (Product Owner) klären, was ein „Zeichen“ ist – sinnvoll ist meist „sichtbares Zeichen“ (in Java z. B. über codePointCount oder BreakIterator) – und die Festlegung in der Anforderung dokumentieren (1 P).

• Testfälle ergänzen: 40 Buchstaben (gültig), 39 Buchstaben plus ein Emoji, 41 Buchstaben (ungültig) und ein zusammengesetztes Emoji; zusätzlich ein Test, der den gespeicherten Titel wieder aus der Datenbank liest (Integrationstest) (1 P).

Die Methode stellt die normalen Aufträge (W-12, W-15) vor die Express-Aufträge (W-18, W-17); innerhalb jeder Gruppe stimmt die Reihenfolge nach Abgabedatum (1 P). Comparator.comparing(Auftrag::express) sortiert nach der natürlichen Ordnung von Boolean, und dort gilt false < true (1 P). Aufsteigend sortiert landen die Express-Aufträge (true) deshalb am Ende; die Gruppen sind also genau vertauscht (1 P).

3      sortiert.sort(Comparator.comparing(Auftrag::express, Comparator.reverseOrder())
4                              .thenComparing(Auftrag::abgabe));

Ebenso richtig: Comparator.comparing(Auftrag::express).reversed().thenComparing(Auftrag::abgabe) – reversed() wirkt hier nur auf das erste Kriterium, weil es vor thenComparing steht. Bewertung: Umkehrung des ersten Kriteriums 1 P, zweites Kriterium unverändert aufsteigend 1 P.

List.of(...) liefert eine unveränderbare Liste. sort versucht, sie umzuordnen, und bricht mit einer UnsupportedOperationException ab; der Test schlägt mit dieser Ausnahme fehl (1 P). Das ist ein Laufzeitfehler: Der Code wird übersetzt, das Programm bricht erst bei der Ausführung ab (1 P).

Bei einer ArrayList läuft die Methode zwar durch, sortiert aber die Liste des Aufrufers um, denn sortiert und auftraege verweisen auf dasselbe Objekt. Das verletzt die Anforderung „übergebene Liste bleibt unverändert“; andere Programmteile, die die ursprüngliche Reihenfolge brauchen, liefern plötzlich andere Ergebnisse (Seiteneffekt) (2 P).

Ergänzung (2 P):

sortiert.sort(Comparator.comparing(Auftrag::express, Comparator.reverseOrder())
                        .thenComparing(Auftrag::abgabe)
                        .thenComparing(Auftrag::nummer));

Testfall (2 P): Eingabe W-21 und W-20, beide nicht express, beide mit Abgabe am 10.11.2026, in dieser Reihenfolge; erwartet: W-20, W-21. Ohne Ergänzung sind beide Aufträge für den Comparator gleich. List.sort sortiert stabil und lässt gleiche Elemente in der Eingabereihenfolge – das Ergebnis wäre W-21, W-20.

Hinweis: Die Auftragsnummern werden als Text verglichen. Das klappt nur, solange alle Nummern gleich viele Ziffern haben („W-9“ käme sonst nach „W-10“).

Die Rückgaben werden von unten nach oben eingesetzt. Die Abweichung entsteht auf Ebene 1: Der Rest 6 wird als 6 statt als 006 angehängt (Aufrufe und Werte 2 P, Stelle der Abweichung 1 P).

Je Klasse mit passendem Testwert 1 P.

Besonders aufschlussreich sind die Grenzwerte 1000 (1.000, die Methode liefert 1.0) und 1099 bzw. 1100.

Den Rest immer dreistellig mit führenden Nullen ausgeben (2 P):

5      return tausenderPunkte(zahl / 1000) + "." + String.format("%03d", zahl % 1000);

Alternativ: Nullen von Hand ergänzen (rest < 10 → "00", rest < 100 → "0" voranstellen).

Prüfung am Anfang der Methode (2 P):

if (zahl < 0) {
    throw new IllegalArgumentException("Betrag negativ");
}

Ohne diese Prüfung gibt die Methode z. B. für -2500 den Text "-2500" zurück, weil -2500 < 1000 gilt.

Beim Schreibtischtest führt ein Mensch den Algorithmus mit Testdaten gedanklich bzw. auf Papier aus (z. B. mit Datenverlaufstabelle); er hilft, einen Fehler zu verstehen, und funktioniert auch für Pseudocode und Entwürfe, ist aber aufwendig und fehleranfällig (1 P). Ein Unit-Test führt den echten Code automatisch aus und vergleicht selbst mit dem erwarteten Ergebnis; er lässt sich nach jeder Änderung beliebig oft wiederholen (1 P).

Je Testfall 1 P.

Je Variante 1 P für Test mit tatsächlichem Ergebnis, 1 P für die Ursache.

• Variante L scheitert an T3: Ergebnis 6,90 € statt 0,00 €. Beim Warenwert wird nur getEinzelpreis() addiert, die Menge fehlt; die zwei Packtaschen zählen nur mit 55,00 €. Bei T2 fällt der Fehler nicht auf, weil 12,00 € und 36,00 € beide unter 100,00 € liegen.

• Variante T scheitert an T4: Ergebnis 98,00 € statt 104,90 €. Der Warenwert wird für jede Position addiert, also auch für die Räder (fehlender else-Zweig). Der Paketwarenwert erscheint dadurch mit 1.607,50 € statt 9,50 €, und die Pauschale entfällt.

Die Zahl bestandener Tests sagt nichts darüber, wie schwer ein Fehler wiegt oder wie oft er auftritt. Leas Fehler trifft Bestellungen, bei denen erst die Menge den Paketwarenwert auf 100 € oder mehr hebt: Kund*innen zahlen dann eine Pauschale, die nicht anfällt. Tims Fehler trifft jede Bestellung mit Rad und Paketartikeln unter 100 €: Der Shop verschenkt die Pauschale. Entscheidend ist, wie häufig die Fälle sind und welcher Schaden größer ist; beide Fehler müssen vor dem Release behoben werden (2 P).

Beide Varianten lassen sich mit einer Änderung korrigieren (2 P für eine davon):

• Variante L: warenwert = warenwert + p.getMenge() * p.getEinzelpreis();

• Variante T: den Warenwert nur im else-Zweig addieren:

  if (p.istRad()) {
      raeder = raeder + p.getMenge();
  } else {
      warenwert = warenwert + p.getMenge() * p.getEinzelpreis();
  }

Jede begründete Entscheidung ist richtig. Danach werden alle Tests erneut ausgeführt (Regressionstest).

T1 durchläuft die Initialisierungen, die Schleife mit dem if-Zweig (Rad) und die Rückgabe; die Pauschalen-Bedingung ist falsch. T2 durchläuft den else-Zweig und, weil der Warenwert zwischen 0 und 100 € liegt, auch die Anweisung versand = versand + 6.90;. Zusammen ist damit jede Anweisung mindestens einmal ausgeführt: 100 % Anweisungsüberdeckung (2 P).

Trotzdem bestehen beide Tests, der Fehler bleibt unentdeckt. Anweisungsüberdeckung zeigt nur, welcher Code ausgeführt wurde, nicht, ob er mit den richtigen Daten geprüft wurde. Den Fehler deckt erst ein Testfall mit Menge > 1 auf, dessen Warenwert die Grenze von 100 € erreicht (T3) (1 P).

530 < 650 ist wahr – tatsächliches Ergebnis True. Erwartet: 120 + 120 + 60 + 350 = 650 W, das ist höchstens 650 W, also ebenfalls True.

Das Ergebnis stimmt nur zufällig: Die Funktion rechnet mit 530 W statt 650 W. Ein einzelner erfolgreicher Testfall beweist also nicht, dass der Code richtig ist.

Bewertung: drei Zeilen der Tabelle je 1 P, tatsächliches und erwartetes Ergebnis zusammen 2 P.

• Zeile 3: Die Schleife beginnt bei Index 1, das erste Gerät wird nie addiert. range(start, ende) läuft in Python von start bis ausschließlich ende; der erste Index ist 0.

  3      for i in range(0, len(leistungen)):

  Ebenso richtig: for leistung in leistungen: oder summe = sum(leistungen).

• Zeile 5: „Höchstens“ schließt den Grenzwert ein; < liefert bei genau 650 W fälschlich False.

  5      if summe <= grenze_w:

Bewertung: je Fehler Zeile 1 P, Beschreibung 1 P, korrigierte Zeile 1 P.

Beim zweiten Testfall ist der erste Wert 0, damit der Startindex das Ergebnis nicht beeinflusst und nur der Grenzwert geprüft wird. Andere Testfälle mit derselben Wirkung sind richtig, z. B. [400, 300] mit Grenze 650 (erwartet False, tatsächlich True).

Bewertung: je Testfall Eingabe und erwartetes Ergebnis 1 P, Begründung 1 P.

Es handelt sich um einen Laufzeitfehler: Das Programm lässt sich starten, bricht aber bei der Ausführung von Zeile 4 mit einer Ausnahme ab. IndexError: list index out of range bedeutet, dass auf einen Index zugegriffen wird, den die Liste nicht hat. Die Liste hat vier Elemente mit den Indizes 0 bis 3; nach der vierten Folie ist aktuell gleich 4 (2 P).

Ursache ist Zeile 6: aktuell wird ohne Obergrenze erhöht (1 P).

Korrektur mit dem Modulo-Operator, der nach dem letzten Index wieder bei 0 beginnt (2 P):

 6      aktuell = (aktuell + 1) % len(folien)

Ebenso richtig: if aktuell == len(folien): aktuell = 0 nach der Erhöhung. len(folien) statt der festen Zahl 4 sorgt dafür, dass neue Folien ohne Codeänderung mitlaufen.

csv.DictReader verwendet die Kopfzeile der Datei als Schlüssel des Dictionarys. Einen Schlüssel "Raum" gibt es nicht, nur "raum"; Python unterscheidet Groß- und Kleinschreibung. Der Zugriff auf einen fehlenden Schlüssel löst einen KeyError aus (1 P).

6              if zeile["raum"] == raum and zeile["beginn"] <= uhrzeit < zeile["ende"]:

Korrigierte Zeile 1 P.

Die Uhrzeiten sind Zeichenketten und werden deshalb Zeichen für Zeichen verglichen, nicht als Zeitangaben (1 P):

• Session 1: "9:30" <= "9:45" ist wahr, aber "9:45" < "10:20" ist falsch, weil schon das erste Zeichen entscheidet: "9" kommt nach "1".

• Session 2: "10:35" <= "9:45" ist wahr ("1" vor "9"), "9:45" < "11:20" ist falsch.

Keine Bedingung ist vollständig erfüllt, die Funktion gibt "Pause" zurück (1 P).

Korrekturen (je 1 P):

• Daten vereinheitlichen: Alle Uhrzeiten zweistellig schreiben (09:30, Format HH:MM), sowohl in der Datei als auch beim Aufruf. Dann stimmt die Reihenfolge der Zeichenketten mit der zeitlichen überein. Das ist aber fehleranfällig, weil jede neue Eingabe sich daran halten muss.

• Als Zeit vergleichen: Die Texte in Zeitwerte umwandeln, z. B. mit datetime.strptime(text, "%H:%M").time(), und erst dann vergleichen. Das funktioniert auch mit 9:30.

Der KeyError ist ein Laufzeitfehler: Das Skript startet, bricht aber bei der Ausführung von Zeile 6 ab. Der Vergleich von Zeichenketten ist ein semantischer Fehler: Das Skript läuft ohne Meldung, liefert aber ein falsches Ergebnis (1 P).

Leichter übersehen wird der semantische Fehler: Für Sessions ab 10 Uhr stimmt das Ergebnis (z. B. "10:45" → „Barrierefreie Websites bauen“). Er fällt nur mit einem Testfall vor 10 Uhr bzw. über die Grenze 9:59 / 10:00 auf (1 P).

Je sinnvollem Schritt 1 P, z. B.:

1. Fehlschlagenden Fall wählen: Die Funktion mit pruefe_last([700], 650) aufrufen, erwartet ist False.

2. Haltepunkt setzen: auf Zeile 3 (Schleifenkopf) bzw. Zeile 4 und das Programm im Debug-Modus starten.

3. Werte beobachten: i, leistungen[i] und summe in die Beobachtungsliste (watch) aufnehmen bzw. in der Variablenansicht verfolgen.

4. Schrittweise ausführen: mit step over Zeile für Zeile weitergehen. Der Debugger springt von Zeile 3 direkt zu Zeile 5, Zeile 4 wird nie erreicht; summe bleibt 0. Bei der Liste [120, 120, 60, 350] zeigt sich entsprechend, dass i bei 1 beginnt und der erste Wert fehlt.

Der Debugger zeigt so, wo der tatsächliche Ablauf vom erwarteten abweicht; dass False erwartet ist, weißt Du aber nur aus der Anforderung.

Die Aussage trifft nicht zu. Der Debugger zeigt, was das Programm tut, aber nicht, was es tun soll: Einen semantischen Fehler wie < statt <= erkennst Du nur, wenn Du das erwartete Ergebnis kennst – genau das hält ein Testfall fest (1 P). Der Debugger untersucht außerdem nur den Fall, den Du gerade ausführst; Unit-Tests prüfen viele Fälle automatisch und nach jeder Änderung erneut (Regressionstest) (1 P). Fehlende Anforderungen, z. B. ein nicht behandelter Sonderfall, findet er ebenfalls nicht. Sinnvoll ist beides: Tests zeigen, dass ein Fehler vorliegt, der Debugger hilft, ihn einzugrenzen (1 P).

import pytest
from strom import pruefe_last

@pytest.mark.parametrize("leistungen, grenze_w, erwartet", [
    ([700], 650, False),                 # nur ein Gerät, über der Grenze
    ([0, 650], 650, True),               # genau auf der Grenze
    ([120, 120, 60, 350], 650, True),    # Summe genau 650 W
    ([120, 120, 60, 351], 650, False),   # 1 W über der Grenze
    ([], 650, True),                     # keine Geräte angeschlossen
])
def test_pruefe_last(leistungen, grenze_w, erwartet):
    assert pruefe_last(leistungen, grenze_w) == erwartet

Bewertung: Dekorator mit Parameternamen und Liste von Datensätzen 1 P, Testfunktion mit passenden Parametern und assert 1 P, Testfälle aus ac) 1 P, Grenzwert und Wert direkt darüber 1 P, leere Liste mit erwartetem Ergebnis True (Summe 0 W) 1 P. pytest meldet jeden Datensatz als eigenen Testfall.

Bei TDD wird der Test vor dem Code geschrieben, in kurzen Zyklen: Zuerst einen Test schreiben, der fehlschlägt (Red), dann gerade so viel Code, dass er erfolgreich ist (Green), danach den Code aufräumen, ohne dass ein Test rot wird (Refactor) (2 P).

Für pruefe_last hätte Emre die beiden Testfälle aus ac) als automatisierte Tests zuerst formuliert, z. B. assert pruefe_last([700], 650) is False und assert pruefe_last([0, 650], 650) is True. Die fehlerhafte Fassung wäre dann sofort rot gewesen; nach der Korrektur bleiben die Tests als Regressionstests erhalten (1 P).