226-2 Objektorientiert implementieren

In der Einführung Stub- und Mock-Klassen wird nun gezeigt, dass es Fälle gibt, wo es schwierig ist, eine Klasse isoliert zu testen. In solchen Fällen arbeitet man mit sogenannten Stub- oder Mock-Objekten. Dazu gibt es Werkzeuge, wie JUnit, welche es erlauben, einen Unit-Test automatisiert und beliebig oft durchzuführen. Nach jeder Änderung an der Klasse kann der Test wiederholt werden. Damit ist sichergestellt, dass die Klasse alle bisherigen Anforderungen nach wie vor erfüllt. Man spricht von Regression-Tests. Oft ist es nicht möglich ein Klasse vollständig isoliert zu testen, weil sie von anderen Klassen abhängig ist. Dies ist der Fall, wenn eine Klasse Objekte anderer Klassen referenziert (über Instanzvariablen) oder wenn sie beim Aufruf ihrer Methoden Referenzen auf Objekte anderer Klassen empfängt (als Argument). In solchen Fällen müssen im Test zusätzliche Objekte bereitgestellt werden, welche nicht im Zentrum des Tests stehen. Man spricht hier von Kollaborationsobjekten (collaborator objects). Dies in Abgrenzung zum eigentlich zu testenden Objekt, welches oft als system under test (SUT) bezeichnet wird. Im einfachsten Fall spielen Kollaborationsobjekte im Test die Rolle von reinen Dummies. Das heisst, sie werden herumgereicht, aber nicht weiter bearbeitet. Oft werden Sie aber auch in den Test mit einbezogen, indem auch bei ihnen Bedingungen überprüft werden, welche durch das SUT eingehalten werden müssen. Schwieriger wird es, wenn das SUT darauf angewiesen ist, dass sich die Kollaborationsobjekte nach einem bestimmten Muster verhalten. Das heisst, dass die Kollaborationsobjekte beim Aufruf ihrer Methoden bestimmte, vordefinierte Resultate liefern. Das kann einiges Kopfzerbrechen geben, wenn sich hinter einem Kollaborationsobjekt ein ganzes Subsystem, wie ein Datenbank, oder ein GUI versteckt. In diesen Situationen arbeitet man dann mit sogenannten Stubs („Stummeln“) oder gar mit Mocks (von Mock-up, Attrappe). Dies sind Klassen, welche die gleiche Schnittstelle wie das Original anbieten, dahinter aber eine auf den Test zugeschnittene Funktion implementieren.

Stub-Klassen

Eine Stub-Klasse ist eine Klasse, welche die gleichen Methoden, wie die Originalklasse anbietet. Allerdings werden die Methoden nicht vollständig implementiert, sondern sie liefern beim Aufruf nur für den Test vorprogrammierte Resultate. Auf alles, was ausserhalb dieser Vorprogrammierung liegt kann eine Stub-Klasse nicht reagieren. Stub-Klassen können Informationen über die aufgerufenen Methoden sammeln. Diese Informationen können später im Test überprüft werden. Eine Stub-Klasse wird in der Regel von Hand für einen bestimmten Testfall programmiert und ist entsprechend eingeschränkt in ihren Möglichkeiten. Sie kann nicht ohne weiteres für andere Testfälle eingesetzt werden.

zeichneTest mit Stub.mp4

Mock-Klassen

Eine Mock-Klasse ist eine Klasse, welche ebenfalls die gleichen Methoden, wie die Originalklasse anbietet. Sie ist aber viel flexibler als eine Stub-Klasse. Die Methoden können vor dem Test mit einem beliebigen Verhalten konfiguriert werden. Dazu werden je nach Werkzeug Regeln eingesetzt (wenn … dann …). Auch bei der Überprüfung bieten Mock-Klassen viel mehr Möglichkeiten. So kann direkt überprüft werden, ob eine bestimmte Methode wirklich mit den erwarteten Argumenten aufgerufen worden ist. Auch die Reihenfolge und Anzahl der Aufrufe kann überprüft werden. Für die Erstellung von Mock-Klassen setzt man normalerweise ein Werkzeug wie Mockito oder jMockit ein.

zeichneTest mit Mock.mp4

Zur Vertiefung wird folgender Artikel empfohlen:

Mockito-Kurzanleitung

Diese Anleitung bietet die wichtigsten Grundlagen zum Testen mit Mockito. Weitere Hilfe ist unter dem folgenden Link zu finden. Nachfolgend sind obige Anweisungen in einem Beispiel-Test zusammengefasst. In diesem Test wird für die List-Schnittstelle aus der Java-Bibliothek eine Mock-Klasse erstellt. In einem realen Test würde diese Mock-Klasse dann für den Test einer weiteren Klasse eingesetzt. Das ist hier nicht so, da es nur darum geht die verschiedenen Möglichkeiten von Mockito aufzuzeigen. Es gibt also keine weitere zu testende Klasse in diesem Beispiel.

import static org.mockito.Mockito.*;
import static org.junit.Assert.*;
import org.junit.Test;
import org.mockito.InOrder;

import java.util.List;

public class MockitoKurzanleitung {

  private List liste = mock(List.class);

  @Test(expected = RuntimeException.class)
  public void test() {
    InOrder order = inOrder(liste);

    when(liste.get(0)).thenReturn("Meier");
    when(liste.get(999)).thenThrow(new RuntimeException());

    assertEquals("Meier", liste.get(0));
    assertEquals(null, liste.get(1));

    verify(liste).get(0);
    verify(liste, times(1)).get(0);
    verify(liste, times(2)).get(anyInt());

    order.verify(liste).get(0);
    order.verify(liste).get(1);

    liste.get(999);
  }


                                                            

person.mp4

Wie Sie bereits aus dem Vorgängermodul wissen, sind Sequenzdiagramme das Mittel der Wahl, wenn es darum geht die Abläufe zur Laufzeit des Programmes zu dokumentieren. Ein Sequenzdiagramm zeigt einen Ausschnitt – einen Film – aus dem Leben des Programms. Es zeigt die während einer bestimmten Zeit vorhandenen Objekte und den Ablauf der Methodenaufrufe bei diesen Objekten. Letzteres wird auch als Abfolge von Meldungen bezeichnet, welche die Objekte einander senden.

UML Tutorial #11 - Sequenzdiagramme

Sequenzdiagramm.mp4

Wie Sie bereits im Vorgängermodul gesehen haben, bieten Klassendiagramme eine gute Übersicht über die statische Struktur eines Programmes. Dies trifft genau gleich auch auf Programme zu, in denen mittels Vererbung übersichtlicher und redundanzfreier Programmiercode entwickelt wurde. Damit die Vererbung in Ihren Klassendiagrammen ersichtlich ist, sollten Sie die dazugehörigen UML-Darstellungsregeln anwenden bzw. lesen können.

Klassendiagramme mit UML - Theoretische Objektorientierte Konzepte 1

Klassendiagramme mit UML - Theoretische Objektorientierte Konzepte 2

Klassendiagramme mit UML - Theoretische Objektorientierte Konzepte 3

Klassendiagramme mit UML - Theoretische Objektorientierte Konzepte 4

Die Ganze Reihe der TheSimpleInformatics ist nur empfhlenswert.