Die Grundlage einer guten Testautomatisierung in der Softwareentwicklung sind Unit Tests. Um wirklich gute Unit Tests zu schreiben, gibt es ein paar Faustformeln dafür, wie ein Unit Test aussehen sollte. Eine davon ist die AAA-Regel.
AAA steht dabei für:
- Arrange
- Act
- Assert
und beschreibt den Aufbau eines Unit Tests.
Im Arrange wird die Startsituation des Tests definiert. Die Komponente wird erzeugt und initialisiert, Mocks werden erzeugt, gesetzt und evtl. das Verhalten der Mocks definiert, Variablen werden gesetzt.
Im Act wird die eigentliche Aktion, die das zu verifizierende Ergebnis erzeugen soll, durchgeführt. In der Regel ist das der Aufruf der Methode, deren Verhalten getestet werden soll. Ein guter Unit-Test besteht dabei aus nur einem Aufruf. Ist mehr als ein Aufruf notwendig, ist das ein Hinweis darauf, dass mehr als nur ein einfacher Aspekt getestet wird! Das ist dann kein Unit Test mehr.
Und schlussendlich wird im Assert überprüft, ob das erwartete Ergebnis durch das Act erzielt wurde. Hier gilt, dass nur ein einzelnes fachliches Ergebnis geprüft werden soll. Dabei liegt die Betonung darauf, dass auf ein fachliches Ergebnis geprüft wird, nicht ein technisches. Das bedeutet nicht zwangsläufig, dass dafür nur ein einzelnes Assert-Statement verwendet werden darf. Wenn über mehrere Vergleiche verschiedene Teilaspekte des fachlichen Ergebnisses überprüft werden müssen, dann ist das schon in Ordnung. Wenn allerdings z.B. ein Unit-Test TestInsertKunde im Assert prüft, ob der Kunde wirklich in die Datenbank geschrieben UND ein entsprechender Logeintrag im Logfile erzeugt wurde, dann ist das ein Hinweis darauf, dass hier mehr als nur ein einzelner Aspekt getestet wurde. So simple und vielleicht manchmal auch nervig, wie die Einhaltung der AAA-Regel scheinen mag, sie hilft, echte Unit Tests zu identifizieren.
In dem Beispiel sehen wir, dass Act und Assert in einer Zeile, quasi ineinander verschachtelt stehen. Hier kann man argumentieren, dass für die bessere Lesbarkeit dieses zu trennen sind. Also den Schlag des Spielers in einer einzelnen Zeile und das Ergebnis daraus in einer lokalen Variable fangen und dann diese im Assert auswerten.
Ob das der besseren Lesbarkeit und Wartbarkeit wegen wirklich notwendig ist, ist schwer objektiv zu beurteilen. Deshalb überlassen wir diese Entscheidung denen, die mit dem Code und den Tests arbeiten müssen.