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

[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 von Rollo62:

<OT>
Das kann schnell bescheuert aussehen.
Das will man den lieben Kollegen doch nicht antun
</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 von TiGü:

Zitat von Rollo62:

<OT>
Das kann schnell bescheuert aussehen.
Das will man den lieben Kollegen doch nicht antun
</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.

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

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 von 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 ?

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 von Rollo62:

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.