N-unit-testen (Testing)
| Back to OverviewCodequalität - was das
Einheilteiche Programmierung erleichtert das lesen, und da du bei PSP 500x länger den Soft-Reset Bug gesucht hast, als das eigentliche Schreiben, ist es deswegen auch praktisch. Außerdem ermöglicht es die Zusammenarbeit, aber das ist egal jeder programmiert lieber alleine.
Unter Codequalität fällt auch die Formatierung (wie viele Leerzeichen, Tabs, etc.), Benennungen und die Dokumentation (Docstring, etc.), Fehlerbehandlung...
Manches lässt sich gut automatisch prüfen und vereinheitlichen (heißt linting)
Es ist tendenziell schlauer Code anderer als Paket/Bibliothek/Framework wiederzuverwenden, als ihn selbst zu schreiben. Natürlich muss man auch hier aufpassen das man keine scheiße einbindet.
Test Driven Development
Wir werden gleich sehen was und wie unit-tests sind. In kurz: sie testen eine unteilbare unit (z.B. eine Methode). Test Driven Development heißt dann:
Zuerst Test schreiben, dann eigentliche unit schreiben, bis der Test grün ist, dann optimieren und wieder neue Tests schrieben, die anderes abdecken. Wiederholen
Ist natürlich praktisch für die Coverage:
Coverage ist der Prozentanteil des Codes, der durch Tests überprüft wird
Tests
Okay also was für Tests gibt es?
- Anforderungsanalyse: Falls der Kunde zustimmt gilt der Test als bestanden (Akzeptanztests)
- System-Architektur: Systemtest testet das Gesamtsystem auf unerfüllte Funktionalität oder Fehler.
- Entwurf: Integrationstests testen die Zusammenarbeit der einzelnen Komponenten.
- Software-Architektur: Unit-Tests testen einzelne Komponenten auf Funktionalität und Fehlerfreiheit.
Das Zeil von verschieden Testfällen ist die Äquivalenzklassen der Ausgaben abzudecken und auf Spezifikation zu testen (Äquivalenzklassen heißt hier: 2+1 ist das gleiche wie 3+1 aber 0-1 ist irgendwie anders). Hier muss man also die Edge-Cases der Software entdecken und testen
Es gibt zwei Arten von Tests:
- Blackbox: Testet das Verhalten des Systems auf die Spezifikation, aber nicht die Implementierung
- Whitebox: Testet die Implementierung des Systems
Bei Whitebox Tests, kann man sich den Kontrollfluss einer Methode richten um die Testfälle zu finden.
Unit Tests
Sind mit Abstand die wichtigsten Tests. Sie testen einzelne Komponenten auf Funktionalität und Fehlerfreiheit.
Eine Bibliothek die hier für Java relevant ist ist: JUnit. Beispieltest:
// file AccountTest.java
import org.junit.*;
public class AccountTest{
@Test
public void testCreateAccount() {
Account account = new Account("Anna");
assertEquals("Anna", account.getCustomer());
assertEquals(0, account.getBalance());
}
}
Kontrollflussgraphen
Weil es natürlich viel zu einfach wäre einfach die scheiß Tests zu schreiben wirst du höchst wahrscheinlich vorher einen Kontrollflussgraphen erstellen müssen.
Kontrollflussgraphen sind einfach die Abzweigungen die ein Programm machen kann dargestellt. Bei if gibts zwei Pfade, bei while den nach unten und den dadrunter :D
Hier ein Bespiel: Angenommen man haben diesen Code (den ich natürlich nirgendwo gefunden habe (ws 2013))
public static int[] sort(int[] a) {
int i = 0;
while (i < a.length -1){
int m = i; int j = i+1;
while (j < a.length){
if (a[j] < a[m]){
m = j;
}
int t = a[i]; a[i] = a[m]; a[m] = t; j++;
}
i++;
}
return a;
}
Der Kontrollflussgraph sieht dann so aus:
Überdeckungstests
Es gibt drei verschiedene Arten von Überdeckungstests, die man dann aus einem solchen Kontrollflussgraphen ziehen kann:
- Anweisungsüberdeckungstest: Jede Anweisung wird mindestens einmal ausgeführt
- Zweigüberdeckungstest: Jeder Zweig wird mindestens einmal ausgeführt
- Pfadüberdeckungstest: Start bei Startknoten und Ende bei Endknoten. Dazwischen immer zum nächst höheren Knoten (Bei Schleifen, natürlich nicht immer möglich).
- Bounded-interior test: Alle Schleifen nur n-mal durchlaufen (z.b. einmal)
Wenn man jetzt beispielweise gefragt werden würde
Geben Sie ein minimales Eingabearray für einen Anweisungsüberdeckungstest an.
Würde das vielleicht so lauten:
Geben sie nun einen Pfadüberdeckungstest an, oder erläutern sie warum es keinen geben kann.