Unit-Testen mit Mocks

[fastjack]

Hallo,

angenommen ich habe folgende grob skizzierte Klassen:

package a;
class A1 implements A {
    public MyComplexResult compute(int i) {
        MyComplexResult mcr = ...
        // sehr komplexe Berechnung mit DB Zugriff etc. etc.
        return mcr;
    }
} 

package b;
class B1 implements b {
    private A a1 = ...
    // z.B. wird a1 im Konstrukter von b1 gesetzt.

    public boolean evaluate(int i, String s) {
        // Berechnungen ...
        MyComplexResult mcr = this.a1.compute(i);
        // weitere Berechnungen ...
        boolean b = ...
        return b;
    }
}

Man kann nun Unittests für a1 schreiben, die die Methode compute() testen, soweit kein Problem.
Auch für B1 lassen sich Unittests schreiben, man kann A1 sehr leicht "wegmocken", indem man einfach einen Mock in den Konstruktor von B1 gibt. Dadurch kann ich ein bereits "richtiges" Ergebnis als Grundlage für meinen Test der Methode evaluate() benutzen, ohne die "komplexen" Berechnungen wirklich auszuführen. Auch kein Problem Das sind alles Unittests.

Jetzt stellt sich mir folgende Frage: Was passiert, wenn jemand die Funktionalität von A1 so ändert, das das MyComplexResult mit völlig anderen Werten befüllt ist und den Test von B1 NICHT anpaßt.
Auf Unitebene würde das überhaupt niemandem auffallen, B1 würde immer noch durchlaufen, da es ja mit den für B1 "richtigen" Grundlagen arbeitet. Das wäre nicht der Fall, wenn A1 nicht weggemockt werden würde, dann würde B1 sofort Fehler beim Testen geben.

Ich vermute hier müßten Integrationstests greifen. Aber dann müßten Unittests UND Integrationstests geschrieben werden, wobei man sich dann fragen könnte, ob die Mocktests wirklich einen Zweck haben.

Was denkt Ihr dazu ?

Hoffentlich ist es verständlich

Danke.

 

[FArt]

Man muss sich immer die Frage stellen: was will ich mit dem Test erreichen? Wie kritisch ist der Code? Wie oft gibt es Änderungen?

Prinzipiell sind Unit-Tests für sehr klein Bereiche gedacht. Dass man da mit Mocks und Vorbedingungen arbeitet ist ok. Man kann aber sehr gut mit JUnit auch weit darüber hinausgehende Tests realisieren. Das ist eine Frage der Handhabbarkeit. Wenn der Gesamtdurchlauf "compute" eine Stunde dauert, ist das sicher nichts mehr für den regelmäßigen Build. Wenn das (und das ist nicht unrealistisch) auch mal mehrere Stunden dauert, ist das u.U. auch nichts mehr für eine CI-Build oder Nightly-Build, auch wenn die Sicherheit, die man dadurch bekommt natürlich wächst.

 

[maki]

Ich vermute hier müßten Integrationstests greifen. Aber dann müßten Unittests UND Integrationstests geschrieben werden, wobei man sich dann fragen könnte, ob die Mocktests wirklich einen Zweck haben.

Mocks nutzt man nur in isolierten Unittests, Integrationstests nutzen keine.
Ansonsten: Ja, ob Klassen/Komponenten im verbund miteinander funktionieren erfährt man nur im Integrationstest.

Isolierte Unittests sind speziell (und nur mit Mocks oder Stubs sind sie wirklich isoliert), gehören zu den Whiteboxtests und testen das zu testende Subjekt isoliert, sind sehr nützlich, aber ersetzen keine Integrationstests, man braucht beide Testarten.

 

[Andi_CH]

In deinem Fall wird ja der Unit Test Abweichungen melden - wenn du dann diesen Anpasst und vergisst dass andere Tests auch angepasst werden müssen ist das menschlich und davor schützt dich kaum ein Tool ;-)

Unit Tests testen eine Unit - und zwar total isoliert. Und der Intergationstest baut ein Gesamtsystem zusammen und testet es. Soweit die Theorie / der Idealfall.

Bei etwas grösseren Systemen braucht es Zwischenschritte.

Unit Tests habe ich vor allem für Libraries und Baseunits, die wenig bis gar keine Abhängigkeiten von anderen Units haben, gemacht. Von denen habe ich nicht unbedingt Mocks erstellt, weil die ja gestet waren.

Einerseits habe ich von Tests generierte Ausgangsdaten als Eingangsdaten für Folgetests verwendet, was genau genommen kein Unit Test mehr ist (Wenn ein Fehler auftritt stellt sich die Frage ob es an den Daten oder am Programm liegt!) , und andererseits habe ich die UUT gleich mit den "echten getesteten units und den Mocks der noch ungetesteten units zusammengelinkt und einen Miniintegrationstest gemacht.

 

[fastjack]

Wie würdet Ihr jetzt in diesem Beispiel vorgehen? Unittests schreiben mit Mocks und zusätzlich einen Integrationstest, oder nur einen Test ohne Mocks?

 

[maki]

Wie gesagt, Unittests mit Mocks und dann nochmal Integrationstests.

Nebenbei, das erzeugen von mockobjekten/Dummydaten etc. lagert man am besten in eine eigene Utilityklasse aus, sonst führen irgendwann minimale Änderungen am Prod. Code zu sehr vielen Änderungen am Testcode, das übliche DRY etc.

 

[Andi_CH]

Details musst du logischerweise selbst entscheiden, aber mach es so wie ich oben beschrieben haben.

Unit test mit Mocks der Basis Units ohne Abhängigkeiten

Und die kritischen zwei Unit die gut miteinander auskommen sollten:
Die zweite von denen Mocken und die erste Testen - mit dem Mock von 1 und wenn nötig mit den echten Base units.

Dann die zweite mit der ersten und den Base units testen