Teil 3: Testen mit Faktor-IPS

Testfalltyp für Beitragsberechnung Hausrat

Für den Testfalltypen erweitern wir die Package-Struktur unterhalb des Sourcefolders "modell" im Projekt faktorips-tutorial-hausratmodell um das IPS-Package "test".

Mit dem Kontextmenü Neu ► Testfalltyp im Model Explorer legen wir einen neuen Testfalltypen an (alternativ können Testfalltypen auch über das Icon NewTestCaseType in der Toolbar angelegt werden):

testfalltyp anlegen
Figure 1. Neuen Testfall-Typen anlegen

Nachdem wir im folgenden Dialog den Namen des Testfalls BeitragsberechnungHausratTest definiert haben, öffnet sich der Editor für Testfalltypen (s. Abbildung 2). Auf der linken Seite sehen wir die (zunächst leere) Struktur des Testfalls, auf der rechten Seite jeweils die Details zu den Elementen der Struktur. Wir beginnen, die Struktur unseres Testfalls anzulegen. Testfalltypen werden in einer Baumstruktur erfasst. Zunächst werden wir also das Wurzelelement definieren. Dazu rufen wir mit Neu…​ den Wizard zum Anlegen von Testparametern auf. Zunächst müssen wir die Art des Testparameters bestimmen. Es gibt drei Arten von Testparametern (zunächst unabhängig davon, ob diese als Eingabeparameter oder erwartete Ergebnisse benutzt werden):

  • Vertragsteilklasse

  • Wert

  • Regel

Für unseren Testfalltyp, mit dem wir die Beitragsberechnung von Hausratverträgen testen wollen, wählen wir als Wurzelelement die Art Vertragsteiltyp:

root parameter anlegen
Figure 2. Testfalleditor: neues Root-Element anlegen

Nun wählen wir als Datentyp unsere Vertragsteilklasse HausratVertrag. Der Name wird mit dem Namen des Datentypen vorbelegt, dies belassen wir für unser Beispiel auch so. Im Feld Typ können wir spezifizieren, welche Funktion der Parameter im Testfall hat:

  • Eingabe
    Attribute der Vertragsteilklasse dienen ausschließlich als Eingabedaten für Testfälle

  • Erwartetes Ergebnis
    Attribute der Vertragsteilklasse dienen ausschließlich als erwartete Werte der Testfälle

  • Eingabe und erwartetes Ergebnis
    Attribute der Vertragsteilklasse können entweder Eingabeparameter oder erwarteter Wert sein

Für unser Beispiel wählen wir Eingabe und erwartetes Ergebnis als Parametertyp, da wir an den zu definierenden Hausratverträgen sowohl Eingabeparameter als auch das erwartete Ergebnis, in unserem Fall der berechnete Beitrag, definieren wollen:

datentyp definieren
Figure 3. Datentyp des Testparameters definieren

Auf der nächsten Dialogseite des Wizards kann die Kardinalität der Parameter einschränkt werden (bei Wurzelparametern allerdings nicht weiter, es gibt immer genau einen). Zusätzlich kann spezifiziert werden, ob der Parameter im Test durch einen Produktbaustein konfiguriert werden muss. Wir setzen die Checkbox Benötigt Produktbaustein und bewirken damit, dass bei der Definition der Testfälle für jeden Hausratvertrag das zu verwendende Hausratprodukt spezifiziert werden muss:

kardinalitaet festlegen
Figure 4. Kardinalität und Produktabhängigkeit festlegen

Die Kardinalität und das Kennzeichen, ob eine Konfiguration durch einen Produktbaustein notwendig ist, kann natürlich auch noch nachträglich direkt im Testfalltyp-Editor geändert werden.

Nun gilt es zu spezifizieren, welche Attribute zu testen sind, und welche als Eingabeparameter dienen. Zunächst werden wir das Attribut nettobeitragZw als erwartetes Ergebnis der Testfälle anlegen. Hierzu wählen wir in der Strukturansicht (links) die Beziehung zur Vertragsteilklasse HausratVertrag aus und legen auf der rechten Seite mit Neu…​ ein neues Testattribut an, welches auf einer Vertragsklasse basiert:

testattribut anlegen
Figure 5. Testattribut anlegen

Im folgenden Dialog können die Attribute der Vertragsteilklasse ausgewählt und in den Testfalltyp übernommen werden.

testattribut auswaehlen
Figure 6. Testattribut auswählen

In unserem Fall erfassen wir die Parameter nettobeitragZw, versSumme, plz und zahlweise. Danach werden auf der Detail-Seite des Editors die Attribute und ihr Typ angezeigt. Das abgeleitete Attribut /nettobeitragZw wird automatisch mit dem Typ Erwartetes Ergebnis vorbelegt, die weiteren Attribute dienen uns als Eingabeparameter.

testtypeditor testattribute
Figure 7. Testtype-Editor mit Testattributen des Hausratvertrags

Jetzt erweitern wir die Struktur unseres Testfalltyps um alle weiteren notwendigen Elemente . Wir nehmen die Vertragsteilklassen HausratGrunddeckung und HausratZusatzdeckung in den Testfalltyp auf. Dazu markieren wir in der Struktur das Element HausratVertrag und erzeugen jeweils mit Neu…​ die Beziehungen HausratGrunddeckung und HausratZusatzdeckungen. Für HausratGrunddeckung wählen wir als Typ Eingabe, als Kardinalität 1..1 und setzen die Checkbox Benötigt Produktbaustein. Für die HausratZusatzdeckungen wählen wir als Type Eingabe, als Kardinalität 0..* und setzen ebenfalls die Checkbox Benötigt Produktbaustein. Zur Erinnerung: Die Auswahl der Checkbox bedeutet, dass die jeweilige Vertragsteilklasse im Testfall durch einen Produktbaustein konfiguriert werden muss. Wir werden dies später sehen, wenn wir einen Testfall anlegen.

kindparameter
Figure 8. HausratGrunddeckung als Kind-Eingabeparameter von Hausratvertrag definieren.

Danach sollte der Testfalltyp-Editor so aussehen:

beziehungen
Figure 9. Beziehung von HausratVertrag zu HausratZusatzdeckung

Damit haben wir definiert, dass mit unserem Testfalltyp eine Instanz eines Hausratvertrags, mit einer Grunddeckung und beliebig vielen Zusatzdeckungen getestet werden kann. Jede Vertragsteilklasse muss sich auf einen konkreten Produktbaustein beziehen.

Wenn wir den Testfalltypen speichern, wird im Source-Verzeichnis des Projekts faktorips-tutorial-hausratmodell im Package org.faktorips.tutorial.hausrat.model.test eine zugehörige Java-Klasse generiert, die den Namen des Testfalltypen trägt, und in der wir die Testlogik implementieren. Wechseln wir auf den Package-Explorer und schauen uns zunächst die Struktur der generierten Klasse genauer an:

public class BeitragsberechnungHausratTest extends IpsTestCase2 {
    //...
    private HausratVertrag inputHausratVertrag;

    private HausratVertrag erwartetHausratVertrag;

    public void executeBusinessLogic() {
        //...
    }

    public void executeAsserts(IpsTestResult result) {
        // begin-user-code
        // TODO : Hier muessen die durchzufuehrenden Pruefungen implementiert werden.
        throw new RuntimeException(
                "Keine Pruefungen vorhanden. Diese muessen in der Java-Klasse, die den Testfalltyp repraesentiert, implementiert werden.");
        // end-user-code
    }
}

  • Membervariablen inputHausratVertrag und erwartetHausratVertrag vom Typ HausratVertrag:
    Da wir den Root-Parameter HausratVertrag als "Erwartetes Ergebnis und Eingabeparameter" festgelegt haben, sind zwei entsprechende Instanzvariablen angelegt worden. inputHausratVertrag enthält die Eingabewerte des Testfalls, gemäß der Definition der Eingabewerte im Testfalltyp. erwartetHauratVertrag enthält die im Testfall erwarteten Ergebnisse (gemäß der Definition im Testfalltyp). Zur Testfalllaufzeit haben wir so zwei Instanzen von HausratVertrag, die wir miteinander vergleichen können.

  • leere Methode executeBusinessLogic():
    In dieser Methode wird die zu testende Geschäftslogik aufgerufen. Zum Beispiel durch Aufruf einer Methode auf den Eingabeobjekten (hier inputHausratVertrag).Die Methode wird ausgeführt, bevor die Methode executeAsserts(…​) aufgerufen wird.

  • Testmethode executeAsserts():
    Hier wird der Vergleich von Ist- und Sollwerten implementiert. Zunächst ist hier eine Default-Implementierung generiert, die den Test fehlschlagen lässt, um eine Implementierung durch den Entwickler zu erzwingen.

Bevor wir die Klasse BeitragsberechnungHausratTest abschließend implementieren, legen wir im nächsten Kapitel einen Testfall an, der auf unserem Testfalltyp basiert.