Von 0 auf 100 - Delphi.Mocks ein Mockframework für Delphi

[generic]

Hallo DP,

in den "Von 0 auf 100" Videos stelle ich kurz eine Technologie vor.
In diesem Video stelle ich die Delphi.Mocks vor. Dieses ist ein Framework zum erstellen von Objekt-Instanzen ohne diese konkret programmieren zu müssen. Das kann z.B. für Unittests genutzt werden.

Hier ist das Video:
https://youtu.be/BjMW4VW1UgA

Das Framework kann hier herunter geladen werden:
https://github.com/VSoftTechnologies/Delphi-Mocks

[Der schöne Günther]

Gestern noch stellt Bernd Ua Spring 4D Mocks vor, jetzt du mit dem Gegenstück Delphi.Mocks. Irre.

Und ich mache das immer noch wie ein Bauer von Hand (bzw. mit einer eigenen 50-Zeilen-Unit), denn auch bei den Spring4D Mocks konnte ich bislang noch nicht erkennen was der Mehrwert gegenüber "von Hand" ist. Mal sehen ob mich Delphi.Mocks überzeugen kann 😁

Vielen vielen Dank für die Mühe.

[TurboMagic]

Ach, der schöne Günter ist/war auch auf der EKON? ;-)

[Der schöne Günther]

Klar, ich bin immer dort wo man mich am wenigsten erwartet 😎


Vielen Dank, das Video zeigt wirklich sehr schön was einen erwartet. Da ich fast nur selten Methoden habe die simple Typen (Integer, Strings, ...) erwarten oder zurückliefern bin ich immer noch skeptisch ob ich da mit den Fluent Interfaces so glücklich werden würde.

Wahrscheinlich würde ich das alles immer über .WillExecute(..) lösen...

[Stevie]

Hauptvorteil von "automatischen" Mocks ist, dass man pro Benutzung nur das "implementieren" muss, was man für einen Test benötigt (oder auch gar nix, wenn man nur ein Stub braucht).
Refactorings der gemockten API führen potenziell zu weniger Änderungen der Tests, als wenn das händisch in Mocks implementiert ist.

Und richtig genial wirds, wenn man Tests hat, die einem das SUT automatisch erzeugen und dort alle Abhängigkeiten als Mocks injected (Stichwort auto mocking container)

[dummzeuch]

Wieder eine schöne Einführung in ein Thema, mit dem ich mich bisher viel zu wenig (nämlich eigentlich gar nicht) beschäftigt habe. Danke dafür.

Und noch ein Lob: Deine Videos, die ich mir bisher angesehen habe, kommen relativ gut auf den Punkt. Andere sind leider häufig so ausschweifend, dass es Zeitverschwendung ist, sie zu schauen.


(Abgesehen natürlich davon, dass ich mir Videos im Büro nicht anschauen kann, da ich sonst die Kollegen nerve. Im Moment bin ich im Home Office, da geht das.)

[generic]

Zitat:

Zitat von TurboMagic (Beitrag 1450458)

Ach, der schöne Günter ist/war auch auf der EKON? ;-)

EKON ist cool, leider war ich zuletzt bei der 14 :-(

Spring hatte ich immer mal auf den Schirm, mir das anzuschauen. Bin aber nie dazu gekommen.
Stevie hatte mich neulich schon drauf hingewiesen, dass es dort schöne Dinge drin gibt.

Mit Delphi.Mocks komm ich persönlich super zurecht und wie das dann so ist, man bleibt auf den bekannten Sachen hängen.

[TiGü]

Zitat:

Zitat von dummzeuch (Beitrag 1450499)

(Abgesehen natürlich davon, dass ich mir Videos im Büro nicht anschauen kann, da ich sonst die Kollegen nerve. Im Moment bin ich im Home Office, da geht das.)

Kopfhörer sind keine Option?

[Rollo62]

<OT>
Das kann schnell bescheuert aussehen.
Das will man den lieben Kollegen doch nicht antun :stupid:
</OT>

[dummzeuch]

Zitat:

Zitat von TiGü (Beitrag 1450529)

Zitat:

Zitat von dummzeuch (Beitrag 1450499)

(Abgesehen natürlich davon, dass ich mir Videos im Büro nicht anschauen kann, da ich sonst die Kollegen nerve. Im Moment bin ich im Home Office, da geht das.)

Kopfhörer sind keine Option?

Nein, sind sie nicht.

[TurboMagic]

Zum Thema Ekon 14: selber schuld, dass du seitdem nicht mehr hingegangen bist?

Zu Spring: Stefan Glienke hat auch erzählt, dass V2.0 in einer Alpha Version
schon von ein paar Leuten erfolgreich eingesetzt wird und das API sich nach
seiner aktuellen Einschätzung wohl nicht mehr großartig ändern wird.

Wenn ich seine Ekon Präsentation richtig verstanden habe, kann man damit Generics
Code "Bloat" richtig gut eindämmen.

Aber auch ich muss mir Spring mal endlich anschauen...

Grüße
TurboMagic

[TiGü]

Zitat:

Zitat von Rollo62 (Beitrag 1450530)

<OT>
Das kann schnell bescheuert aussehen.
Das will man den lieben Kollegen doch nicht antun :stupid:
</OT>

Na ja, ich war gedanklich eher bei kleinen In-Ear-Kopfhörern, so dass man auch ganz leicht nur mit einer Seite einem Video zuhören kann.

[dummzeuch]

Zitat:

Zitat von TiGü (Beitrag 1450584)

Zitat:

Zitat von Rollo62 (Beitrag 1450530)

<OT>
Das kann schnell bescheuert aussehen.
Das will man den lieben Kollegen doch nicht antun :stupid:
</OT>

Na ja, ich war gedanklich eher bei kleinen In-Ear-Kopfhörern, so dass man auch ganz leicht nur mit einer Seite einem Video zuhören kann.

Auch die Dinger kann ich absolut nicht ab. Ich stamme noch aus einer Zeit, als man noch nicht ständig mit einem Knopf im Ohr herumlief. Mir graut schon davor, wenn ich irgendwann ein Hörgerät brauchen sollte. Aber wir kommen "etwas" vom Thema ab.

[Stevie]

Nur mal so als Teaser, warum Spring.Mocking besser ist als Delphi.Mocks. 8-)

Ich arbeite gerade, dass man das Mock Setup aus dem Video bei ca 21:00 so schreiben kann:

Delphi-Quellcode:

ml.Setup.Returns(True).When.TryGetOperation(Arg = 'm', Arg.Ref(mo.Instance).Return);

Syntax und Benamung für den Out Parameter Teil ist noch nicht final.

[Rollo62]

Die Mocks sind sehr interessant für die Entwicklung von neuen Klasse im Team, so setze ich das auch teilweise ein.
Mich würde aber mal interessieren ob man Mocks auch zum Erweitern von bestehenden, aktiven Klassen einsetzen sollte,
also auch generell im produktiven Umfeld in echten Applikationen ?

Ich denke es spricht nichts dagegen, aber es könnte auch sein das Mocks da an gewissen Stellen Probleme machen (Speicherbedarf, Timing, usw.).
Wann sollte man das besser nicht produktiv nutzen, wenn überhaupt ?

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1450654)

Die Mocks sind sehr interessant für die Entwicklung von neuen Klasse im Team, so setze ich das auch teilweise ein.
Mich würde aber mal interessieren ob man Mocks auch zum Erweitern von bestehenden, aktiven Klassen einsetzen sollte,
also auch generell im produktiven Umfeld in echten Applikationen ?

Ich denke es spricht nichts dagegen, aber es könnte auch sein das Mocks da an gewissen Stellen Probleme machen (Speicherbedarf, Timing, usw.).
Wann sollte man das besser nicht produktiv nutzen, wenn überhaupt ?

Beißt es sich nicht im Konzept schon, im produktiven Betrieb Mocks einzusetzen, die halt nix oder nur einen Ersatz ausführen, anstatt des produktiven Verhaltens?
Was du vermutlich eher meinst, sind dynamische Proxies, die man hinter Interfaces schalten kann, und die vor der eigentlichen das Interface implementierenden Klasse noch Zusatzlogik ausführen, oder?

[Rollo62]

Naja, ich meinte schon existierende Klassen etwas zu erweitern.

Es könnte dabei schon Sinn machen und diese Klassen dann eben mit noch nicht 100% ausprogrammierten Erweiterungen benutzt werden können.
Es passiert ja schonmal das man eine alte Klasse um eine kleine Schnittstelle erweitern muss.

Ich habe jetzt gerade auch kein tolles Beispiel, aber es kommen ja immer von aussen neue Anforderungen hinzu (zumindest ist das bei mir oft so).
Vielleicht als Beispiel eine Erweiterung 1FA zu 2FA:

Delphi-Quellcode:

//alte Klasse: 
function CanGenerate_1FA_Token : String;  // funktionert alles, wird produktiv eingesetzt
function Generate_1FA_Token : String;  // funktionert alles, wird produktiv eingesetzt
//Erweiterung: 
function CanGenerate_2FA_Token : String;  // gemocht, im RELEASE immer False
function Generate_2FA_Token : String;  // gemockt im Test, aus gegebenem Anlass, wird das erweitert

Ist vielleicht ein blödes Beispiel, im Moment fällt mir aber nichts Besseres ein.
Natürlich setzte ich mal voraus das beide Funktionen relativ unabhängig sein sollten, und sich deshalb nicht "beissen" dürfen.

Dein Vorschlag würde ja unter Umständen ein ziemliches Redesign bedeuten, was vielleicht gar nicht immer nötig ist, also warum nicht in der Übergangsphase mocken ?

Man kann natürlich auch die Erweiterung erst komplett fertigstellen, und danach erst freigeben, aber falls soetwas mal länger dauern sollte dachte ich (naiv wie ich bin), wäre das Mocken eventuell auch eine Option.

Ich verstehe deine Antwort mal so das Mocks dafür eher nicht geeignet sind um während der
Erweiterungsphase etwas dranzubauen.

Rollo

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1450662)

Ich verstehe deine Antwort mal so das Mocks dafür eher nicht geeignet sind um während der
Erweiterungsphase etwas dranzubauen.

Irgendwer implementiert ja schon das bestehende Interface und somit müssen auch die neuen Methoden implementiert werden, sonst kompilierts nicht.
Dort kann man ja dann Dummy Verhalten einbauen - dafür braucht man keine Mocks, wie sie hier Thema sind.

Mocks, wie sie hier thematisiert wurden sind dafür da, in Unit tests ebend nur genau das implementieren zu müssen, was die getestete Komponente benötigt. Dies ist in vielen Fällen ja pro Test nur ein Teil eines gegebenen Interfaces mit bestimmten Eingaben und ggf Ausgaben. Und dafür muss man dann das Interface nicht herkömmlich in einer Klasse implementieren. Etwas, was in Produktionscode schon gegeben ist, aber erweitert werden soll. Und selbst wenn es ein komplett neues Interface gibt, muss es irgendwann implementiert werden, somit wäre der Gebrauch eines Mocks hier auch unnötig.

Wofür sich Mocks aber durchaus eignen, ist Prototyping - wenn ich nur bestimmte Teile ausprobieren möchte, aber diese durchaus noch weitere Komponenten benutzen, die ich im Prototyp gerade nicht benutzen möchte oder kann. Dann ersetzen die dort ähnlich wie in einem Unit- oder Integrationstest diese Teile.