Verständisproblem bei JUnit-Tests

[smash]

Ich schau mir grad JUnit4 an. Ich habe JUnit bisher kaum verwendet und überlege derzeit es in einem neuen Projekt einzusetzen. Vielleicht soger ein wenig in Richtung Test Driven Development zu arbeiten. Allerdings habe ich da noch so meine Probleme, den Sinn derartiger Unittests zu verstehen.

Die Vorteile der Unittests sind mir klar. Kommen wir lieber zu dem Haken, den ich da sehe:

Wie baut man gute Tests auf?

Ich meine, bei einfachen Methoden könnte man ja das Ergebnis von Hand vorgeben. Spätestens bei komplexen Objecten geht dass nicht mehr. Das heißt, ich muss neuen Code schreiben um ein Referenzobject zu erzeugen, das dem Object verglichen werden kann, dass aus der zu testenden Methode kommt.

Das wäre doppelte Arbeit und die Referenzimplementierung kann ebenso fehlerhaft sein.

Habe ich da was falsch verstanden?

Wie baut man JUnittests richtig?

Wie setzt man Unittests richtig ein?

Ich hoffe ihr könnt mich erleuchten. Vielen Dank im Voraus.

[kingofbrain]

Servus,

vom Prinzip hast Du Unit Testing schon ganz gut verstanden, denke ich. Der Aufbau der Referenzobjekte bleibt Dir nicht erspart, diesen Aufwand muss man einfach mittragen.

Wichtig ist in meinen Augen, dass man beim echten Unit-Tests nur die Komponente an sich testet, nicht Komponenten, die von der zu testenden Komponente verwendet werden. Beispiel: Du hast eine Serviceklasse (z.B. KundenService), und die benötigt zwei DAO-Objekte, um Zugriffe zum persistenten Datenspeicher zu kapseln (z.B. PersonenDao und VertragsDao). Die Abhängigkeit zu den DAOs möchte man nicht mittesten, da ein Fehler im DAO als Fehler in der Serviceklasse aufschlagen würde. Deshalb verwendet man Stub-, oder Mockobjekte bzw. Dummyimplementierungen (such mal im Internet, was die im Einzelnen bedeuten, das geht schneller, als wenn ich es ausschweifend erkläre ). Für das Mocking von Objekten in Java gibt es z.B. EasyMock.

Dann überlegst Du Dir, welche Fälle es beim Aufruf einer Methode geben kann (unvollständige Parameter, null-Referenzen, verschiedene Varianten im Algorithmus, und auch den Erfolgsfall nicht vergessen). Bei Test First schreibst Du diese Annahmen jetzt in einem Test auf und lässt ihn laufen. Er muss natürlich fehlschlagen, weil Du noch keine Implementierung hast. Jetzt schreibst Du eine Implementierung, damit Deine Tests erfolgreich durchlaufen werden.

Der wirkliche Vorteil liegt jetzt nicht in der ursprünglichen Entwicklung Deiner Methoden, sondern beim Refactoring oder bei der Weiterentwicklung. Alle bestehenden Tests spiegeln Deine (fachlichen) Erwartungen an den Algorithmus wider. Diese sollen ja in der Regel bei einer Erweiterung oder Änderung der Klasse weiter erfüllt werden. Du hast also über die bestehenden Tests eine gute Möglichkeit der Regressionstests.

Ich hoffe, das hilft Dir ein wenig weiter.

Peter