Hallo Christian,
zuerst mal ein gutes neues Jahr.
Deine Einschätzung ist richtig. Das Hauptproblem ist ja, dass man für den Unittest nur einen kleinen Teil davon braucht. Und das ist nur der Datenteil. Alles, was mit der Swing-Anwendung selbst zu tun hat, das braucht man eigentlich nicht. Die Trennung ginge etwas Richtung MVC-Pattern. Und den reinen Datenteil im Test hochzufahren, geht vermutlich einfacher.
Allerdings würde ich das bei uns in der Firma auch nicht als gutes Design durchgehen lassen (wegen der komplexen Singletons). Das eigentliche Problem ist, dass die statischen Methoden in PositionHelper auf das aktuelle Singleton durchgreifen. Und da kann man nicht einfach was anderes setzen.
Was man da auch machen könnte ist, dass man den PositionHelper in ein Singleton oder sogar zu einer ganz normalen Klasse umwandelt und dann keine statischen Methoden mehr hat. In Klassen, die den benutzen wolle, die können den PositionHelper sich im Konstruktor bestimmen bzw. erzeugen und benutzen bei den Aufrufen dann diese Instanz. Gleichzeitig gibt es zusätzliche Konstruktoren für die Unittests, bei dem man den PositionHelper auch von aussen vorgeben kann bzw. die benötigten Modelle alternativ vorgeben kann.
Hier könnte man auch ein Interface definieren, die die RouteConverter-Klasse implementiert. Beim Test gibt man dann eine eigene Variante von dem Interface durch, wo man nur den benötigten Teil mit Leben füllt.
In PositionHelper sähe das so aus:
Und den PositionHelper kann man dann über deine Callback-Klasse in das PositionsModelImpl durchreichen.
Ich hoffe, dass du mir etwas folgen konntest. Solche Dinge nur in einem Chat zu diskutieren, mache ich sonst nicht. Da machen wir meist kurze Calls bei uns in der Firma zu. Da kann man dann auch die ganzen Vor- und Nachteile der verschiedenen Lösungen besser diskutieren.
Gruß
Thomas
zuerst mal ein gutes neues Jahr.
Deine Einschätzung ist richtig. Das Hauptproblem ist ja, dass man für den Unittest nur einen kleinen Teil davon braucht. Und das ist nur der Datenteil. Alles, was mit der Swing-Anwendung selbst zu tun hat, das braucht man eigentlich nicht. Die Trennung ginge etwas Richtung MVC-Pattern. Und den reinen Datenteil im Test hochzufahren, geht vermutlich einfacher.
Allerdings würde ich das bei uns in der Firma auch nicht als gutes Design durchgehen lassen (wegen der komplexen Singletons). Das eigentliche Problem ist, dass die statischen Methoden in PositionHelper auf das aktuelle Singleton durchgreifen. Und da kann man nicht einfach was anderes setzen.
Was man da auch machen könnte ist, dass man den PositionHelper in ein Singleton oder sogar zu einer ganz normalen Klasse umwandelt und dann keine statischen Methoden mehr hat. In Klassen, die den benutzen wolle, die können den PositionHelper sich im Konstruktor bestimmen bzw. erzeugen und benutzen bei den Aufrufen dann diese Instanz. Gleichzeitig gibt es zusätzliche Konstruktoren für die Unittests, bei dem man den PositionHelper auch von aussen vorgeben kann bzw. die benötigten Modelle alternativ vorgeben kann.
Hier könnte man auch ein Interface definieren, die die RouteConverter-Klasse implementiert. Beim Test gibt man dann eine eigene Variante von dem Interface durch, wo man nur den benötigten Teil mit Leben füllt.
In PositionHelper sähe das so aus:
Code:
PositionHelper() {
this(RouterConverter.getInstane());
}
PositionHelper(RouteConverterIfc routeConverter) {
this.routeConverter = routeConverter;
}Und den PositionHelper kann man dann über deine Callback-Klasse in das PositionsModelImpl durchreichen.
Ich hoffe, dass du mir etwas folgen konntest. Solche Dinge nur in einem Chat zu diskutieren, mache ich sonst nicht. Da machen wir meist kurze Calls bei uns in der Firma zu. Da kann man dann auch die ganzen Vor- und Nachteile der verschiedenen Lösungen besser diskutieren.
Gruß
Thomas