Teil 3: Testen mit Faktor-IPS

Sonderfall: Testen von abgeleiteten Attributen

Bisher haben wir die Vergleichslogik im Testfalltyp aufgrund des Vergleichs von Membervariablen der Testobjekte implementiert. In der Input-Instanz haben wir das Attribut berechnen lassen, in der Erwartet-Instanz haben wir das Attribut mit dem Testeditor eingetragen und die Attribute beider Instanzen verglichen. Es handelte sich dabei um abgeleitete Attribute für die eine Membervariable generiert wird und die erst durch den expliziten Aufruf einer Methode (hier inputHausratVertrag.berechneBeitrag()) berechnet werden. Diese Art abgeleiteter Attribute ("cached") können genauso wie änderbare Attribute getestet werden.

In Faktor-IPS haben wir aber auch die Möglichkeit, abgeleitete Attribute zu definieren, die bei jedem Aufruf der Getter-Methode ("on the fly") berechnet werden. Für diese Attribute wird keine Membervariable generiert. Sie stellen daher einen Sonderfall für die Testimplementierung dar, da wir in unserer Erwartet-Instanz keine Membervariable haben, die wir für einen Vergleich nutzen können.

Die Tarifzone des Hausratvertrags ist ein solches Attribut. Wir erstellen nun wie bereits beschrieben einen neuen Testfalltypen (ErmittlungTarifzoneTest), mit dem wir die Ermittlung der Tarifzone anhand der Postleitzahl überprüfen können.

Als Eingabeparameter definieren wir die Attribute plz der Vertragsteilklasse HausratVertrag. Für HausratVertrag setzen wir die Checkbox Benötigt Produktbaustein. Anstatt die Tarifzone als erwartetes Ergebnis basierend auf der Vertragsteilklasse Vertrag anzugeben, legen wir ein Testfall-Attribut an, das nicht auf einer Vertragsklasse basiert:

testfall ohne vertragsteilklasse
Figure 1. Testfall-Attribute anlegen, dass nicht auf einer Vertragsteilklasse basiert
testattribut tarifzone
Figure 2. Attribut tarifzone definieren

In der generierten Testklasse wird nun eine Konstante generiert, mit der man den Inhalt des Attributs im Testfall lesen kann. Dieses wiederum kann man dann im assert-Statement mit dem berechneten Wert aus der Input-Instanz vergleichen:

public class ErmittlungTarifzoneTest extends IpsTestCase2 {

    /**
     * @generated
     */
    public static final String TESTATTR_HAUSRAT_VERTRAG_TARIFZONE = "tarifzone";

    //...

    /**
     * Fuehrt die zu testende Geschaeftslogik aus.
     *
     * @restrainedmodifiable
     */
    @Override
    @IpsGenerated
    public void executeBusinessLogic() {
        // begin-user-code
        // nichts zu tun (die zu testende Logik wird durch getter-Aufruf ausgeführt)
        // end-user-code
    }

    /**
     * Fuehrt die Pruefungen (Asserts) aus, d.h. vergleicht die erwarteten Werte mit den
     * tatsaechlichen Ergebnissen.
     *
     * @restrainedmodifiable
     */
    @Override
    @IpsGenerated
    public void executeAsserts(IpsTestResult result) {
        // begin-user-code
        String erwartetTarifzone = (String) getExtensionAttributeValue(
            erwartetHausratVertrag, TESTATTR_HAUSRAT_VERTRAG_TARIFZONE);

        String inputTarifzone = inputHausratVertrag.getTarifzone();
        assertEquals(erwartetTarifzone, inputTarifzone, result, "HausratVertrag", TESTATTR_HAUSRAT_VERTRAG_TARIFZONE);
        // end-user-code
    }

    //...
}

Mit inputHausratVertrag.getTarifzone() wird auf die berechnete Tarifzone zugegriffen, mit getExtensionAttributeValue(…​) auf die im Testfalltypen definierte, erwartete Tarifzone.

Zur Überprüfung legen wir einen Testfall (ErmittleTarifzoneTest_1) basierend auf dem neuen Testfalltyp an und befüllen die Testdaten für Plz. Dem HausratVertrag ordnen wir noch ein Hausratprodukt (z.B. HR-Kompakt 2019-07) zu. Gemäß der Tarifzonentabelle erwarten wir für die Postleitzahl 63066 die Tarifzone VI:

testfall tarifzone
Figure 3. Testfall zur Ermittlung der Tarifzone

Nach der Ausführung des Tests bestätigt uns der grüne Balken die Korrektheit des Testfalls.