Server-Responds testen, Code-Redundanz

[ManInBlack]

Hallo Zusammen,

bin mir nicht sicher ob ich mit dem Titel meine Problembeschreibung richtig getroffen habe.

Ich stehe in der Arbeit gerade vor einem Problem.

Versuche es mal kurz zu beschreiben:

Ich habe eine Anwendung programmiert, welche Anfragen an weitere Server stellt .
Meine Anwendung ist ein eigenständig laufendes System und muss, um lauffähig zu sein, hochgefahren werden.

Ich möchte jetzt Anfragen an die anderen Server testen.
Allerdings will ich nicht für den Test meine Anwendung hochfahren (Zieht einen Rattenschwanz mit, dauert seine Zeit, es erfolgen Anfragen an Naming Services, usw...). Ich habe dafür eine simple Client-Klasse geschrieben, die quasi meine komplexe Anwendung simuliert. Diese Clientklasse wird nur zum Testen verwendet.

Funktion des Test: Ist der request an den server erfolgreich und wird der respond richtig zurückgeliefert und verarbeitet.

So jetzt kommen wir zu meinem Problem: 🙂)

Die Methode für die serverAnfrage existiert leider jetzt 2 mal und zwar einmal in meiner Anwendung und dann nochmal in den Testklassen mit unterschiedlicher Signatur.

in meiner Anwendung sieht die Methode so aus und der Parameter ServiceAdapter kann nur dann übergeben werden, wenn meine Anwendung läuft:

getData(ServiceAdapter adapter, Query query,.....)
{
...
ArrayList<E> dataList = adapter.command(query,....)
//her kommen dann noch komplexere Verarbeitungsschritte, was mit der dataList gemacht wird
...
};

und in der Testklasse ähnlich nur dass hier der einfache Client übergeben wird

getData(ClientServiceAdapter adapter, Query query,.....)
{
...
ArrayList<E> dataList = adapter.command(query,....)
//her kommen dann noch komplexere Verarbeitungsschritte, was mit der dataList gemacht wird
...
};

Das ist sehr sehr unschön, da ich einmal quasi mit dem Testclient teste und wenn das dann funktioniert,
wird die Methode getData in meine eigentliche Anwendung kopiert und angepasst mit "ServiceAdapter"

Jetzt meine Frage an euch, wie kann ich das verhindern dass redundanter Code entsteht?


Meine bisherigen überlegungen waren:

a) ein property einführen für Testklasse und einmal für die Anwendungsklasse, ist aber auch nicht so toll, da diese Property in der Anwendung meiner Meinung nach nichts zu suchen hat.

b) das ServiceAdapter-Objekt zu mocken mit einem Mock-Framework, funktioniert bei einfachen Anfragen ganz gut,
aber je komplexer die ServiceAdapter werden (machmal muss man mehrere übergen und es werden mehrere Anfragen an verschiedene Server gestellt) ist das auch nicht mehr optimal
(ich erstelle ein Mock von ServiceAdapter-Objekt und hänge meine ClientServiceAdapter-Objekt dran)


Ich weiß nicht ob jemand, dass verstanden hat und nachvollzogen hat, was ich beschrieben habe, aber ich hoffe mal 🙂
Vielleicht hatte jemand sowas änliches schonmal.

Evtl. danke im Voraus 🙂

Schöne Grüße
ManInBlack

 

[Antoras]

Hört sich nach einem klassischen Implementierungsproblem an. Dein

ServiceAdapter

sollte eine Schnittstelle sein, keine konkrete Implementierung. Dein

ClientServiceAdapter

muss diese Schnittstelle nur implementieren und schon macht es keinen Unterschied mehr mit was für Objekten zur Laufzeit gearbeitet wird. Dein Testcode kann dann mit dem konkreten Objekt

ClientServiceAdapter

und dein Server mit

ServerServiceAdapter

arbeiten. Stichwort für weitere Informationen: Dependency Injection.

 

[maki]

Sagen dir Mockobjekte etwas?
Sind flexibler als Fakes/Stubs 😉

Ich nehme meist JMock2

 

[ManInBlack]

Danke für eure Antworten.
@Antoras Genau auf diese Weise habe ich es jetzt gelöst, war zwar nicht ganz so einfach, weil ich ein Framework verwende. Dies ging dann bloß mit Vererbung und Implementieren der Interfaces bei den vererbten Klassen des Frameworks. Aber ist jetzt super, genauso wollte ich das.

@maki Das war meine erste Lösung, Objekte zu mocken. Ich hab dafür Easymock verwendet, hat zu beginn auch wunderbar funktioniert. Aber die Anzahl der Adapter (werden über Collections, die n-Adapter enthalten, übergeben) wurde mit der Zeit immer größer und dadurch steig auch der Aufwand diese Adapter zu mocken.

Also nochmal danke, bis dann
ManInBlack