Frage zu Mocking

[TigerLilly]

Ich habe mich ein wenig ins Abseits manövriert + hätte gern Ratschläge :- )

Ich habe eine Klasse A, für die ich automatisierte Tests schreibe. Diese Klasse A benutzt eine weitere Klasse B - und zwar ruft sie drei ihrer Methoden auf. Diese Klasse B wird meiner Klasse A im Konstruktor übergeben. Natürlich hat die Klasse B noch viele andere Methoden.

Für meine Tests wollte ich die Klasse B mocken. Aber leider hat die Klasse B keine virtuellen Methoden. Da das 3rd Party code ist, möchte ich den nicht ändern.
Ich möchte aber auch nicht in meinen Tests die ganze Klasse B erzeugen, weil ich für meine Tests die ja gar nicht brauche.

Einen Decorator möchte ich auch nicht schreiben, weil die Klasse B sehr viele Methoden hat.

Ich hab an class helpers gedacht, aber die helfen mir da auch nicht.


Ich bin dankbar für jeden Tipp!

[CarlAshnikov]

Ich würde dir hier eine Proxy-Klasse C schreiben, die nur die Methoden von Klasse B durchleitet die du in A benötigst. Dann lässt du sie noch ein Interface mit den entsprechenden Methoden implementieren und verwendest dies in A. Dein Mock muss dann nur diese Methoden implementieren.

[Stevie]

In der (zumeist englisch sprachigen) Literatur zu dem Thema wird von seams also Nähten gesprochen, an denen man Anhängigkeiten (dependencies) entkoppeln kann. Diese geschieht in der Regel durch virtuelle Methoden oder Interfaces (deren Methoden alle virtuell sind). Es gibt natürlich auch Möglichkeiten, zu mocken, sollte man solche Nähte nicht haben, aber das ist mehr Hack als nützlich.

Ein Weg, eine solche Abhängigkeit aufzubrechen, wäre, entweder eine eigene Ableitung dieser 3rd party Klasse zu machen und ein Interface implementieren zu lassen. Dieses Interface kann dann alle Methoden anbieten die du bisher von der Klasse benutzt bzw die benötigt werden. Sind die Signaturen 1-zu-1 so wie in der Klasse, brauchst du keine einzige Zeile Implementierungscode schreiben. Es können auch verschiedene Interfaces sein (z.B. eins mit den 3 Methoden, die an dieser Stelle gebraucht werden und ein anderes mit 4 Methoden, die an einer anderen Stelle benötigt werden - siehe ISP, das I in SOLID)

Die andere Möglichkeit wäre über einen Adapter, der die 3rd Party Klasse bekommt und seine Methodenaufrufe (diese entweder über ein Interface wie in der zuvor genannten Möglichkeit oder als virtuelle Methoden) an die 3rd Party Klasse weiterzuleiten.

In beiden Fällen musst du natürlich den Code ändern - aber genau das wirst du immer wieder als Empfehlung lesen, denn darum heißt es "wie man testbaren Code schreibt". Es geht genau darum, diese Nähte bereitzustellen, an denen man in einem Test abtrennen und ein Mock an"nähen" kann.

Der Vollständigkeit sei noch erwähnt, dass es auch manchmal die Empfehlung gibt, durch entsprechendes ifdef im Code für Produktion oder für Test zu kompilieren, aber davon möchte ich dir gleich im Vorfeld aus Erfahrung abraten.

[TigerLilly]

Danke für die ausführliche Antwort!

Zitat von Stevie:

Ein Weg, eine solche Abhängigkeit aufzubrechen, wäre, entweder eine eigene Ableitung dieser 3rd party Klasse zu machen und ein Interface implementieren zu lassen.

Das war mein erster Versuch, aber die Methoden der 3rd party Klasse sind ja nicht virtuell.

Zitat:

Die andere Möglichkeit wäre über einen Adapter, der die 3rd Party Klasse bekommt und seine Methodenaufrufe (diese entweder über ein Interface wie in der zuvor genannten Möglichkeit oder als virtuelle Methoden) an die 3rd Party Klasse weiterzuleiten.

Das war der zweite Versuch, aber die 3rd Party Klasse wird an anderer Stelle auch benutzt bzw übergeben + dann bekomme ich Typinkompatibilitäten.

[CarlAshnikov]

Worin besteht das Problem die Klasse einmal hinter einem Proxy/Adapter und einmal ohne diesen zu verwenden? Vielleicht solltest du das mal genauer skizzieren.

[Stevie]

Zitat von TigerLilly:

Danke für die ausführliche Antwort!

Zitat von Stevie:

Ein Weg, eine solche Abhängigkeit aufzubrechen, wäre, entweder eine eigene Ableitung dieser 3rd party Klasse zu machen und ein Interface implementieren zu lassen.

Das war mein erster Versuch, aber die Methoden der 3rd party Klasse sind ja nicht virtuell.

Müssen sie auch nicht - Beispiel:

Delphi-Quellcode:

type
  TWuppdi = class // third party
  public
    procedure DoThings;
    procedure DoOtherThings;
  end;

  IWuppdi = interface
    procedure DoThings;
    procedure DoOtherThings;
  end;

  TInterfacedWuppdi = class(TWuppdi, IWuppdi)
    // möglicherweise noch die 3 IInterface Methoden implementieren
    // hängt davon ab, wovon TWuppdi ursprünglich ableitet
  end;

Dein Code nimmt dann statt einem TWuppdi Objekt das IWuppdi Interface entgegen und das lässt sich ausmocken.

[TigerLilly]

Ich dachte, ich kann nur virtuelle Methoden mocken?

Bei meinem versuch (mit DelphiMocks), das zu so zu machen, wurde anstelle der Mocks immer die Basismethode aufgerufen. Hmmm.

Das muss ich nochmal ansehen. Danke jedenfalls.

[CarlAshnikov]

Wenn du deine Versuche hier mal postest, kann man dir beim Finden des Problems helfen.

[Stevie]

Zitat von TigerLilly:

Ich dachte, ich kann nur virtuelle Methoden mocken?

Bei meinem versuch (mit DelphiMocks), das zu so zu machen, wurde anstelle der Mocks immer die Basismethode aufgerufen. Hmmm.

Das muss ich nochmal ansehen. Danke jedenfalls.

Interface Methoden sind virtual (du mockst ja dann nicht mehr TWuppdi, sondern IWuppdi).
Fürs DelphiMocks oder andere gleichartige mocking libs musst noch {$M+} über das interface machen oder von IInvokable (gleicher Effekt) ableiten.