Lektion 02 - Regressionstests
Regressionstests: Alte Fehler sollen nicht zurueckkommen
Ein Regressionstest prueft, ob etwas, das frueher funktioniert hat, nach einer Aenderung immer noch funktioniert. Regression bedeutet hier: Ein Programm faellt auf einen alten fehlerhaften Zustand zurueck.
1. Was ist eine Regression?
Eine Regression entsteht, wenn du Code aenderst und dadurch eine alte Funktion kaputt machst. Das passiert nicht, weil du schlecht programmierst, sondern weil Software zusammenhaengt. Eine kleine Aenderung an einer Funktion kann Auswirkungen an anderer Stelle haben.
Beispiel:
Vorher:
calculatePrice(100, 20) ergibt 120
Nach Aenderung:
calculatePrice(100, 20) ergibt 100
Problem:
Eine alte Erwartung wurde kaputt gemacht.
2. Warum Regressionstests so wichtig sind
Je groesser ein Projekt wird, desto schwerer ist es, alles manuell zu pruefen. Regressionstests sind wie ein Sicherheitsnetz. Nach jeder Aenderung kannst du automatisch pruefen, ob bekannte Funktionen noch laufen.
3. Beispiel: Bug wird zu Regressionstest
Angenommen, eine Funktion fuer Rabatte hat einen Fehler. Bei einem Rabatt von
0 Prozent soll der Preis gleich bleiben. Frueher wurde aber
versehentlich 0 zurueckgegeben.
import 'package:test/test.dart';
double applyDiscount(double price, double discountPercent) {
return price - (price * discountPercent / 100);
}
void main() {
test('0 Prozent Rabatt laesst Preis unveraendert', () {
expect(applyDiscount(100, 0), 100);
});
test('20 Prozent Rabatt reduziert Preis korrekt', () {
expect(applyDiscount(100, 20), 80);
});
}
Sobald dieser Test existiert, ist der alte Fehler abgesichert. Wenn jemand die Rabattlogik spaeter veraendert und der Fehler zurueckkommt, wird der Test rot.
4. Regressionstest vs. normaler Test
Technisch kann ein Regressionstest genauso aussehen wie ein Unit-Test. Der Unterschied liegt im Zweck: Ein Regressionstest wurde oft geschrieben, weil ein konkreter Fehler schon einmal passiert ist.
5. Wann schreibst du Regressionstests?
- Wenn du einen Bug gefunden hast.
- Bevor du den Bug reparierst, wenn moeglich.
- Wenn ein Grenzwert falsch behandelt wurde.
- Wenn eine wichtige Nutzeraktion kaputt war.
- Wenn du refactorst und das Verhalten gleich bleiben muss.
Gute Regel: Jeder gefixte Bug bekommt mindestens einen Test, damit er nicht wieder unbemerkt auftaucht.
6. Uebungen
- Erfinde einen Bug in einer Funktion
divide(int a, int b). - Schreibe einen Regressionstest fuer Division durch
0. - Schreibe einen Regressionstest fuer einen falschen Rabatt-Grenzwert.
- Notiere: Welcher Fehler war bekannt und was prueft der Test?
- Fuehre gedanklich ein Refactoring aus und erklaere, warum Tests Sicherheit geben.