AAA

Die Grundstruktur jedes Tests.

• Arange
• Act
• Assert

Dependency Injection

Die zu testende Klassen hängt von anderen Objekten ab. Damit wir den Test davon isolieren können, müssen wir diese ersetzen durch Doubles. Wenn die zu testende Klasse die Abhängigkeiten nicht selber erzeugt, sondern von Aussen übergeben bekommt, dann nennen wir das Dependency Injection

Arten von Dependency Injection

• Public Injection
  • Constructor Dependency Injection - Abhängige Objekte werden im Constructor übergeben
  • Setter Injection - Mit einer Setter-Methode wird das DOC übergeben
  • Parameter Injection - Das DOC wird als Parameter der zu testenden Methode mitgegeben
• Private Dependency Injection - Die Abhängigkeit wird in einem privaten Attribut gespeichert. Damit dieses von Aussen gesetzt werden kann, erklärt die CUT Freundschaft zur Testklasse.

Darüber hinaus gibt es noch die Möglichkeit, mit Test Seamsdie Abhängigkeiten zu ersetzen.

Testen auf Zustandsänderungen

Manchmal ändern Methode den internen Zustand eines Objektes, ohne ein Ergebnis zurückzugeben. Ob dieser Zuständsänderung erfolgreich war, kann man auf zweierlei Arten prüfen.

mo_cut->set_msgv1( 'ABC').
cl_abap_unit_assert=>assert_equals( act = mo_cut->mv_msgv1
                                    exp = 'ABC' ). 

mo_cut->set_msgv1( 'ABC').
cl_abap_unit_assert=>assert_cp( act = mo_cut->get_message()
                                exp = '*ABC*' ). 

Data Access Objects (DAO)

Wie auf der letzte Folie gezeigt, sind DAOs eine gute Option zum Ersetzen des Datenbankzustands während des Tests. Ein DAO soll eigentlich nur die Datenbankzugriffe enthalten und möglichst schlank sein.

Mit dem modernen ABAP SQL kann man, gerade beim lesenden Zugriff, viel Logik in die Datenbank drücken (Code-To-Data). Davon sollte man unbedingt Gebrauch machen.

Test von DAOs

• Der Test eines DAOs kann mit Hilfe des SAP SQL Test Double Frameworks erfolgen.
• Die DAOs sollten unabhängig vom Rest der Komponente getestet werden, da dies Tests ggf. etwas länger laufen können.

Wiederverwendung von Code in UnitTests

Auch in UnitTests gilt das DRY Prinzip: Nichts wiederholen. Entsprechend wird sich wiederholender Code in Methoden ausgelagert.

Hilfsmethoden (aka. Testinfrastruktur)

Die eigentliche Testmethode soll vor allem die Daten vorher und nachher zeigen. Und sich darauf fokussieren, was jeweils in den Methoden unterschiedlich ist.
Dazu können Hilfsmethoden verwendet werden, die die eigentliche Testlogik abbilden und die von den Testmethoden aufgerufen werden.

Auslagern von Hilfsmethoden in Superklassen

Die Hilfsmethoden können in eine Superklasse ausgelagert werden. Damit

Globale Testklassen

Es können auch globale Klassen als FOR TESTING markiert werden. Diese können aber nicht direkt ausgeführt werden. Sie können aber von lokalen Testklassen beerbt werden.

Test Driven Development (TDD)

Unter Test Driven Development versteht man ein Vorgehen, bei dem zunächst ein Test geschrieben wird, bevor der produktive Code erstellt wird. Wenn alle Tests grün sind, muss zunächst ein neuer Test geschrieben werden der einen Fehler aufzeigt. Nur dann darf man weiter programmieren.

Mikrozyklus beim TDD

1. Schreibe einen Test, der einen neuen Aspekt abdeckt und der aktuell noch auf rot läuft
2. Korrigiere den Code so, das alle Test auf grün laufen
3. Mache ein Refactoring Deines Codes, so dass
   1. Der Code so sauber, klar und einfach wie möglich ist und
   2. Weiterhin alle Tests grün sind

Beginne von vorne....

Die Dauer eines solchen Mikrozyklus sollte höchstens wenige Minuten betragen.

Testbarer Code

Viele Clean Code Prinzipien erleichtern die Erstellung von testbarem Code. Beispiele:

• Kleine Methoden mit genau einer Aufgabe - Klare Testfälle
• Wenige Parameter - Wenige Tests pro Methode notwendig, weil es nur wenige Kombinationen gibt
• Trennung durch Interfaces
• Klassen mit nur einer Verantwortlichkeit - Eine Trennung eines betriebswirtschaftlichen Objektes (z.B. Benutzer) in mehrere Klassen mit technischen Verantwortlichkeiten kann hilfreich sein, weil beispielsweise die Klasse für den Datenbankzugriff durch ein Test Double ersetzt werden kann

Grundsätzlich bauen wir keine "Abzweigungen" in den Code ein, damit die Tests leichter fallen:

IF p_is_test.
  SELECT * 
    FROM <Tabelle>
    INTO TABLE @lt_table.
ELSE. 
  lt_table = VALUE #( ( salesorderdocument = '10000' 
                        AMOUNT = '123,56'
                        ... ))
ENDIF.